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

[mark.reinhold at oracle.com]

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