Encapsulating internal APIs in JDK 9 (sun.misc.Unsafe, etc.)
richard.warburton at gmail.com
Tue Aug 4 22:48:33 UTC 2015
On Tue, Aug 4, 2015 at 3:48 PM, <mark.reinhold at oracle.com> wrote:
> As part of the overall modularization effort  we're going to
> encapsulate most of the JDK's internal APIs within the modules that
> define and use them so that, by default, they are not accessible to
> code outside the JDK.
> This change will improve the integrity of the platform, since many of
> these internal APIs define privileged, security-sensitive operations.
> In the long run it will also reduce the costs borne by the maintainers
> of the JDK itself and by the maintainers of libraries and applications
> that, knowingly or not, make use of these non-standard, unstable, and
> unsupported internal APIs.
> It's well-known that some popular libraries make use of a few of these
> internal APIs, such as sun.misc.Unsafe, to invoke methods that would be
> difficult, if not impossible, to implement outside of the JDK. To ensure
> the broad testing and adoption of the release we propose to treat these
> critical APIs as follows:
> - If it has a supported replacement in JDK 8 then we will encapsulate
> it in JDK 9;
> - If it does not have a supported replacement in JDK 8 then we will not
> encapsulate it in JDK 9, so that it remains accessible to outside
> code; and, further,
> - If it has a supported replacement in JDK 9 then we will deprecate it
> in JDK 9 and encapsulate it, or possibly even remove it, in JDK 10.
> The critical internal APIs proposed to remain accessible in JDK 9 are
> listed in JEP 260 . Suggested additions to the list, justified by
> real-world use cases and estimates of developer and end-user impact,
> are welcome.
Its great to hear that this pragmatic compromise is being adopted. I hope
over time supported replacements can be found for all the use cases being
addressed with internal APIs, but glad that in the meantime existing
projects won't suffer.
More information about the jigsaw-dev