Controversy brewing

Java 9 without sun.misc.Unsafe: a disaster?

JAX Editorial Team
Argument image via Shutterstock

A sore-point has emerged in the upcoming plans for Java 9, namely the projected absence of the private API used by almost every tool, infrastructure software and high performance library built using Java.

After the debate about the transition to the G1 garbage collector, another controversial issue has emerged for the community. Apparently, the sun.misc.Unsafe API will be removed or disabled by default in Java 9. The DripStat blog is calling it “a disaster in the making”.

Where is the problem?

sun.misc.Unsafe is a private and officially unsupported API, which is still used by many vendors and frameworks in order to achieve high-performance, low-level interactions with things such as the operating system, memory or other hardware features. sun.misc.Unsafe is used by Spring, Hazelcast, Cassandra, Grails, Akka and Hadoop, just to name a few.

As is clear from a discussion on the OpenJDK mailing list, some uncertainty is brewing regarding the statement that private APIs will not be available in JDK 9 due to modularity restrictions. sun.misc.Unsafe is to be disabled by default, despite there being a “a clear need for the features of this class”.

The DripStat blog lamented further about the change. The lack of an Unsafe class (and default flag to enable it) would break not only classical infrastructure software such as Cassandra and Zookeeper, but a plethora of mainstream applications, since so many libraries internally use the class.

The flag to enable Unsafe will become the default flag to launch the JVM henceforth, since without it your Java apps will break without notice. Since most environments won’t have this flag put in their JVM arguments by default, when they upgrade Java on their systems, their software will break.

It’s painted on the wall: a two-tier Java application picture showing their use in a pre- and post- Java 9-time. Backwards compatibility would be broken and the acceptance and distribution of Java 9 would be also disturbed.

Adoption of Java 9 will slow to a crawl due to this, which would effect the entire Java ecosystem. The situation will be analogous to Python 2 and 3.

Solution in sight?

To alleviate potential problems in the meantime, developers have come together and prepared a proposal paper from their point of view. A special Working Group is to be established to secure parts of sun.misc.Unsafe in order to reimplement it under the OpenJDK Project. Even Java performance guru Kirk Pepperdine agrees in principle with this procedure, who said the following in an InfoQ interview:

Do we need to get rid of Unsafe, Yes! Do we need to keep Unsafe? Yes. How do we reconcile these seemingly conflicting positions? Well, we need to plan a migration path to move the stuff that we now know how it should be implemented out of Unsafe and into the JDK proper.

Given the lateness of the venture aiming to save sun.misc.Unsafe, it’s important to note that Java 9 is (expected) to be ready and available on September 22, 2016. We’ll have to wait and see exactly what the final solution will entail.

comments powered by Disqus