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) ch...@hazelcast.com <mailto:ch...@hazelcast.com> +49 160 9648 2677 @noctarius2k skype: noctarius_ > Am 04.08.2015 um 18:29 schrieb Martijn Verburg <martijnverb...@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 <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)
