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

Question

I read here that Spring and many other popular libraries will break if Oracle removes sun.misc.Unsafe in Java 9. However, there are no static references to this class in Spring or Hibernate. So, is that claim true?

BTW there are 64 references to Unsafe in Java 8, but if Oracle removes that class they will update all of them and no library will be affected (unless they use Unsafe directly that is).

Gorden

Unsafe will not be removed from the JDK, just be hidden. So the JDK can internally still access it. This is made possible by the Jigsaw module concept. – Capitation

So what does that mean for the average Java developer compiling their Spring-Hibernate applications to war files using maven and dropping it into Tomcat / Jetty? Will my application start up or will it require fidgeting with the container to make it work? – Raceway

@Lluis Martinez Is there a suitable answer to this already? If yes, could you mark one please. – Lavettelavigne

Answer 1

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.

Delanie

Answer 2

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.

Messick

Answer 3

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

Septempartite

You're right, Guava has a few references but I read they provide a fallback so it's not a hard dependence. github.com/google/guava/… – Gorden

No references in Spring github.com/spring/spring/… – Gorden

@LluisMartinez: Your link points to "Spring RTS game engine", "an Open Source Real Time Strategy game engine". This has nothing to do with the Spring the OP asked about. – Thoth

@Nicolai Which link? I'm the OP by the way :-) – Gorden

The link in this comment. – Thoth

Answer 4

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.

Planogamete