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-boun...@openjdk.java.net] On Behalf
Of mark.reinh...@oracle.com
Sent: Tuesday, August 4, 2015 16:49
To: jigsaw-dev@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
