Is sun.misc.Unsafe public in JDK9?

Question

I just tried JDK9 and found that sun.misc.Unsafe now does not contain its own method, but delegates them to some jdk.internal.misc.Unsafe , for example:

 @ForceInline public int getInt(Object o, long offset) { return theInternalUnsafe.getInt(o, offset); } 

The latter, in turn, is similar to the old sun.misc.Unsafe , but now the methods are annotated with some annotation:

 @HotSpotIntrinsicCandidate public native void putObject(Object o, long offset, Object x); 

So, is it safe to use Unsafe running JDK9? Is this a public official API now?

Answer 1

Here is a good explanation:

https://adtmag.com/blogs/watersworks/2015/08/java-9-hack.aspx

What to do with sun.misc.Unsafe in Java 9? One side says it's just a terrible hack of bad old days to get rid of; the other side says that its heavy use is responsible for the growth of Java into the infrastructure space and popular tools still need it. There is a problem, both sides are right ....

By writing on the OpenJDK mailing list, Reinhold proposed encapsulating unsupported internal APIs, including sun.misc.Unsafe, within the modules that define and use them. This offer is now a formal Java Improvement Suggestion (JEP). Published this week, JEP 260 (“Encapsulate Most Internal APIs”) aims at “most of the internal JDK APIs are not available by default, but leave some critical, widely used accessible internal APIs until they are supported replacements for all or most of their functionality.

Short answer: you should NOT use it in any new application that you are developing from scratch.

Answer 2

@ Paulsm4's explanation is good enough to know whether to use it further or not.

Long Answer ~ JEP 260: Encapsulate Most Internal APIs

---

Why did they decide to remove / depreciate API support for a long time?

Utility

In the _{JEP 200} Modular JDK , restricting access to non-standard, intermittent, and unsupported APIs that are internal parts of the JDK implementation, using the _{JEP 261} Module System improves the integrity and security of the platform , as many of these internal APIs define privileged, security-sensitive operations. In the long run, this change will reduce the costs that accompany the JDK itself and the libraries and applications that, consciously or not, use these internal APIs.

---

Are all internal APIs planned?

Category

The above internal JDK APIs fall into two broad categories: -

• Non-critical internal APIs that do not appear to be used by code outside the JDK or are used by external code just for convenience.

• Critical internal APIs that provide critical functionality that would be difficult, if not impossible, to implement outside the JDK itself (for example, sun.misc.Unsafe ).

---

What if someone translates code that already uses Unsafe , but ultimately plans to move away?

sun.misc.Unsafe

Its one of those critical internal APIs that are not encapsulated in JDK 9, since supported replacements did not exist in JDK 8 when at the same time most other APIs were encapsulated or deprecated for removal in future releases.

Is sun.misc.Unsafe public in JDK9?

• Using

  Currently, to access a critical internal API, such as Unsafe , you need to determine the dependency on the jdk.unsupported module, which is defined specifically for this purpose:

   module jdk.unsupported { exports sun.misc; opens sun.misc; ... } 

➜ As far as he could answer your question, you won’t be able to find this documented module, possibly to limit the users from using this and, obviously, a sign to avoid it, to make it “publicly available”.

• Migration

  The functionality of many methods in the Unsafe class was available through _{JEP 193 Sub} Descriptor Variables _>.