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

[Martijn Verburg]

+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 <jeroen at 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-bounces at openjdk.java.net
> <javascript:;>] On Behalf
> > Of mark.reinhold at oracle.com <javascript:;>
> > Sent: Tuesday, August 4, 2015 16:49
> > To: jigsaw-dev at 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)