+1 to this - it's a really good compromise. Christoph from Hazelcast (and some other folks from popular projects that use Unsafe) have been compiling a list of use cases and a gap analysis of sorts. I'll let him respond here with the gory details to add to the JEP.
Cheers, Martijn On Tuesday, 4 August 2015, Jeroen Frijters <jer...@sumatra.nl> wrote: > 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 > <javascript:;>] On Behalf > > Of mark.reinh...@oracle.com <javascript:;> > > Sent: Tuesday, August 4, 2015 16:49 > > To: jigsaw-dev@openjdk.java.net <javascript:;> > > 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 > -- Cheers, Martijn (Sent from Gmail Mobile)
