Removal of sun.misc.Unsafe in Java 9 - A disaster in the making

Oracle is planning to remove sun.misc.Unsafe in Java 9. This is an absolute disaster in the making and has the potential to completely destroy the entire ecosystem around Java.

Almost every tool, infrastructure software, high performance library built using Java uses sun.misc.Unsafe underneath. Here is a small list from the above linked document itself:

  • Netty
  • Hazelcast
  • Cassandra
  • Mockito / EasyMock / JMock / PowerMock
  • Scala Specs
  • Spock
  • Robolectric
  • Grails
  • Neo4j
  • Spring Framework
  • Akka
  • Apache Kafka
  • Apache Wink
  • Apache Storm
  • Apache Hadoop
  • Apache Continuum

... and the list goes on and on.

However, Oracle seems bound on removing it for no reason. Here is a comment from their mailing list:

Let me be blunt -- sun.misc.Unsafe must die in a fire. It is -- wait for it -- Unsafe. It must go. Ignore any kind of theoretical rope and
start the path to righteousness

This engineer hates the Unsafe class for no real reason at all..

What Oracle should do

The Unsafe class is a force of nature at this point. There is no point running from it. There is a clear need for the features of this class. There is also the fact that almost every java program uses it without even knowing about it since its used in so many popular Java libraries.

1. Document it and make it public

Instead of removing the class, Oracle should accept the reality and and make it a public API with good documentation and examples to go along.

Currently, without any specific documentation, one has to turn to StackOverflow posts or other random blog posts to understand how to work with Unsafe.

A big argument for removing Unsafe is that it is too easy to shoot yourself in the foot with it. Having good, official documentation will prevent this.

2. Release new APIs alongside

Alongside documenting Unsafe, Oracle should also release new, easier to work with APIs that achieve the same functionality. This is part of what is proposed in the above doc. However, this should not come at the cost of removal of Unsafe. As newer software gets written, over time people will automatically stop using Unsafe and prefer the newer APIs.

This is similar to how the new DateTime APIs were introduced in Java 8 in the java.time package. Their inclusion didn't mean that previous DateTime APIs were completely removed or put behind a special flag. That would have been catastrophic.

What will (probably) actually happen

From the way things are heading, it seems Oracle will:

  1. Remove the Unsafe class for normal operation of JVM under Java 9
  2. Enable it only if a special flag is passed to the JVM.

This will result in absolute catastrophy!

  • Almost all Java programs, not just infrastructure software like Cassandra or Zookeeper, but also your web applications, will break, since the libraries they rely on probably uses Unsafe underneath.

  • 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 wont have this flag put in their JVM arguments by default, when they upgrade Java on their systems, their software will break.

  • Java will break its promise of backward compatibility. All libraries/infrastructure software will henceforth have 2 versions:

    1. Pre Java 9 - that uses Unsafe
    2. Java 9 compatible - which does not use Unsafe.
  • 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.

JVM screwups have happened before

Do you think this is too crazy and that Oracle would never make such a mistake? Actually it already did something like this with the bytecode verifier in Java 7.


Now is the time to spread awareness about this issue. Removal of Unsafe from the JVM or putting it behind a special flag will result in absolute catastrophy.

Show Comments