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

[Christoph Engelbert]

Hey Mark, Martijn,

First of all a more official way than twitter: I really appreciate this step, it is the perfect way. Unsafe has to disappear but with a good migration path and I think this compromise will achieve exactly that.

I’ll compile the list in a more readable format over the next days. Unfortunately I most probably can only give use cases about sun.misc.Unsafe (and some less important tricks on other classes, that are not necessary from my point of view), however I guess there might be other classes used by other projects like sun.reflect.ReflectionFactory which is used by Objenesis and couple of other frameworks.



Christoph Engelbert
Technical Evangelist / Senior Solutions Architect 
350 Cambridge Ave Suite #50, Palo Alto, CA 94306 USA (based in Germany) 
chris at hazelcast.com <mailto:chris at hazelcast.com> 
+49 160 9648 2677
@noctarius2k
skype: noctarius_

> Am 04.08.2015 um 18:29 schrieb Martijn Verburg <martijnverburg at gmail.com>:
> 
> +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)