Mark,
Thanks for this. In the list of broad categories, one is missing:
x Those which are required to enable application code to work around
bugs in the JDK such as leaked objects.
When do you expect to be able to publish a detailed proposal for how the
"last resort" mechanism will work?
Simon
mark.reinh...@oracle.com wrote:
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
