Removal of sun.misc.Unsafe in Java 9 will break Spring, Hibernate

Mark Reinhold had a talk during JVM Language Summit 2015 titled The Secret History and Tragic Fate of sun.misc.Unsafe. Although these talks have plenty of disclaimers on them, you can see the proposed approach at 10:23, which is described in JEP260.

The general idea is:

  1. replace existing functionality with safer, supported APIs
  2. deprecate the previously existing Unsafe APIs that has been replaced
  3. remove the deprecated code in the next version

Here is some relevant text from JEP260 (taken from October 20th 2015):

In JDK 9 we propose to:

  • Encapsulate all non-critical internal APIs by default: The modules that define them will not export their packages for outside use. (Access to such APIs will be available, as a last resort, via a command-line flag at both compile time and run time, unless those APIs are revised or removed for other reasons.)

  • Encapsulate critical internal APIs for which supported replacements exist in JDK 8, in the same manner and with the same last-resort workaround. (A supported replacement is one that is either part of the Java SE 8 standard (i.e., in a java.* or javax.* package) or else JDK-specific and annotated with @jdk.Exported (typically in a com.sun.* or jdk.* package).)

  • Not encapsulate critical internal APIs for which supported replacements do not exist in JDK 8 and, further, deprecate those which have supported replacements in JDK 9 with the intent to encapsulate them, or possibly even remove them, in JDK 10.

...

Critical internal APIs for which replacements are introduced in JDK 9 will be deprecated in JDK 9 and either encapsulated or removed in JDK 10.


The answer is in the linked document. Spring does not have a direct dependency on Unsafe, but Spring depends on Objenesis and Objenesis depends on Unsafe.

Dependency for Objenesis on Unsafe: https://github.com/easymock/objenesis/blob/master/main/src/main/java/org/objenesis/instantiator/sun/UnsafeFactoryInstantiator.java

Spring's dependency on Objenesis is itself a bit strange. Spring's build script fetches the Objenesis binary and makes bytecode-level changes using the JarJar tool. You can see what it does in the following build script: https://github.com/spring-projects/spring-framework/blob/master/build.gradle (at time of writing, see lines 326-343, and 347).

This essentially means that Spring's "spring-core" binary ends up containing a load of classes under the org.springframework.objenesis.* package structure, but those classes were originally stored in source in Objenesis GitHub, published as a binary by the Objenesis team, fetched during Spring's build, repackaged to org.springframework.* packages and then republished as part of Spring. That's why you are having trouble finding them.

Spring uses Unsafe (via Objenesis) to create classes without first calling the constructor.


This resource provides a proper understanding of the current status of JDK 9 and its features. The community started a discussion related to Unsafe and its future into the future of java. The given document is the effort of the community to react to JEP-260 that proposes hiding some internal APIs but leaving accessible some critical APIs, among witch Unsafe. As extracted from the document itself:

The critical internal APIs proposed to remain accessible in JDK 9 are:

sun.misc.Cleaner

sun.misc.{Signal,SignalHandler}

sun.misc.Unsafe (The functionality of many of the methods in this class is now available via variable handles (JEP 193).)

sun.reflect.Reflection::getCallerClass (The functionality of this method may be provided in a standard form via JEP 259.)

sun.reflect.ReflectionFactory

So to conclude, at least based on the given JEP, Unsafe should remain.


Maybe the references are not in the core of Spring or Hibernate, but somewhere else. The document linked says with regard to Spring

Spring Framework (via Objenesis, with a fallback)

I tried to search for usages of Unsafe in the project I am currently working on, so there are still quite some libraries which may break.

result of quick search:

  • Guava
  • GWT
  • Netty
  • Jersey-Common
  • Infinispan
  • Jboss-Modules