Encapsulating internal APIs in JDK 9 (sun.misc.Unsafe, etc.)

[Jeroen Frijters]

Hi Mark,

Thanks. This looks like a solid plan. It will put us on track to get rid of the internal API usage without making it needlessly dificult for people to adopt JDK 9.

Regards,
Jeroen

> -----Original Message-----
> From: jigsaw-dev [mailto:jigsaw-dev-bounces at openjdk.java.net] On Behalf
> Of mark.reinhold at oracle.com
> Sent: Tuesday, August 4, 2015 16:49
> To: jigsaw-dev at openjdk.java.net
> Subject: Encapsulating internal APIs in JDK 9 (sun.misc.Unsafe, etc.)
> 
> As part of the overall modularization effort [1] 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 [2].  Suggested additions to the list, justified by
> real-world use cases and estimates of developer and end-user impact, are
> welcome.
> 
> - Mark
> 
> 
> [1] http://openjdk.java.net/jeps/200
> [2] http://openjdk.java.net/jeps/260