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