Is sun.misc.Unsafe become public in JDK9?

Question

I just tried JDK9 and found out that sun.misc.Unsafe is now containing not a native 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 latest, in turn, looks actually like 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 starting JDK9? Is it 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 simply an awful hack from the bad old days that should be gotten rid of; the other side says its heavy use is responsible for the rise of Java in the infrastructure space and popular tools still need it. The problem is, both sides are right. ...

Writing on the OpenJDK mailing list, Reinhold proposed encapsulating unsupported, internal APIs, including sun.misc.Unsafe, within modules that define and use them. That proposal is now a formal Java Enhancement Proposals (JEP). Posted this week, JEP 260 ("Encapsulate Most Internal APIs") aims to "make most of the JDK's internal APIs inaccessible by default, but leave a few critical, widely used internal APIs accessible, until supported replacements exist for all or most of their functionality."

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

Answer 2

The explanation by @paulsm4 is good enough to know whether to use it further or not.

Long Answer ~ JEP 260: Encapsulate Most Internal APIs

---

Why did they decide over removing/deprecating the support of an API used for long?

Usefulness

In The Modular JDK_{JEP 200}, limiting access to non-standard, unstable, and unsupported APIs that are internal implementation details of the JDK by leveraging The Module System_{JEP 261} improves the integrity and security of the platform since many of these internal APIs define privileged, security-sensitive operations. In the long run, this change will reduce the costs borne by the maintainers of the JDK itself and of libraries and applications that, knowingly or not, make use of these internal APIs.

---

Are all the internal APIs planned to be encapsulated?

Categories

The above specified JDK's internal APIs are divided into two broad categories:-

• Non-critical internal APIs which do not appear to be used by code outside of the JDK or are used by outside code merely for convenience..

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

---

What if someone is migrating code that already makes use of Unsafe, but eventually plans to move away?

sun.misc.Unsafe

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

Is sun.misc.Unsafe become public in JDK9?

• Usage

  Currently to access the critical internal API's such as Unsafe, one needs to define a dependency on the jdk.unsupported module which is defined specifically for the purpose:

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

➜ As much as it could answer your question, you won't find this module documented even, probably to restrict consumers from making use of it and clearly a sign of avoiding it to make it "public".

• Migration

  The functionality of many of the methods in the Unsafe class has been made available via Variable Handles _{JEP 193}.