Still Unsafe: The Major Bug in Java 6 That Turned into a Java 9 Feature

With 2015 having just drawn to a close, we thought this would be a good opportunity to do a post-mortem of one of the hottest debates within the Java community over the past year. By looking at the title most of you have probably already started developing a sour taste in your mouths and an angry feeling in your gut, but in case you’ve missed on the action, let us recap what all the fuss was about.

The bottom line: sun.misc.Unsafe isn’t going anywhere

The whole debate started back in July when Oracle was considering the removal of what many developers rely on as one of the key API’s of the JVM – the Unsafe library. The proposal suggested that Unsafe will be fully encapsulated when Java 9 is released and while the release of that version of Java is still quite far away in the future, the mere announcement caused a virtual uproar in the developer community.

We saw Reddit, Twitter and multiple blogs filled with criticism over the move, many developers felt “betrayed” by Oracle because of 3 main reasons:

Unsafe provided access to low-level features that aided in the development of many tools.

Those same features don’t have any alternatives outside of the the internal JVM library.

Many developers were fearful that the encapsulation of sun.misc.Unsafe will negatively impact and even reduce many tools to a state of being unusable.

For the time being, there is a compromise in place, which is a 3 step solution suggested by Mark Reinhold, chief architect of the Java platform group. The solution outlines the desired process for encapsulating internal APIs such as Unsafe:

If it has a supported replacement in JDK 8 then it will be encapsulated JDK 9

If it does not have a supported replacement in JDK 8 then it will not be encapsulated in JDK 9, so that it remains accessible to outside code; and, further,

If it has a supported replacement in JDK 9 then it will be deprecated and encapsulated in JDK 9, or possibly even remove it, in JDK 10.

So the question now becomes this: why would Oracle seek to eliminate Unsafe and kick off this storm to begin with? To understand that we should probably look at things objectively before we make any judgments, one way – or another.

How Unsafe came to be

The only place we can start the process of inspecting the cause for such a firestorm is the Unsafe library itself. Many developers have come to rely on its unique features and functionality for a variety of tasks, however, let’s not forget that the Unsafe library was not in fact meant to be accessible to anyone outside the internal development team in the first place. It was, and still is an irregularity, a coincidence, a bug of sorts.

Sure, it was an extremely useful and happy coincidence, but it was not meant to happen at all. Various Unsafe uses have become practically standard over the years and versions, but the origins of any of those uses remain rooted in error. As such, it is somewhat illogical to expect Oracle to keep the dated sun.* libraries “open for business” indefinitely, after all, if any of us locates a bug in our own code – do we not strive to eliminate it?

The community reacts – A disaster in the making

As the Unsafe storm spread throughout the Java developer community, there were two main issues that kept being brought up. The first was the previously discussed feeling of betrayal (justified or not – depending on your perspective). The second, and perhaps slightly more reasonable – there were legitimate fears that encapsulating Unsafe would, for the first time ever, break one of the key promises of Java – backwards compatibility.

Some developers have been issuing apocalyptic posts about the possible outcomes of eliminating or limiting access to Unsafe saying the many tools, libraries and infrastructure software uses the library, directly or underneath the visible code, that list includes Hazelcast, Cassandra, Spring and quite a few others.

Any developer using one or more of those tools would encounter serious difficulties if Oracle’s plan of encapsulation were to be fully realized.

The Oracle position – “Unsafe must die in a fire”

The very name of the library should indicate that it is risky for use, and all Oracle is really doing is attempting to minimize any potential risks. Using a library titled Unsafe in anything is a bit like seeing a minefield, crossing it once successfully then inviting all of your friends to cross it as well because it “worked for you”.