What does the future hold for sun.misc.Unsafe?
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”. That can only result in one outcome:
Oracle has explained over the years that while they appreciate all the community has done in terms of development using the Unsafe library, access to such a low level library should be seen as risky for use. Irresponsible use of the undocumented library may result in various memory issues and other processing overloads on any platform using it. Which is the very definition of a “less than desirable outcome” where Oracle is concerned. It might be good to note that not all “deprecations” in Java are seen as bad when they happen, some, like the removal of PermGen end up being lauded as extremely positive.
Final Thoughts
It seems though as the Java platform team saw the protest spread (they likely knew it was coming) and ended up finding a reasonable solution to the problem, or at least one that they could live with along with the developer community.
We’re still more than a year away from the actual release of Java 9, with or without the Unsafe library in any way shape or form, and it is likely that other changes and announcements may soon arrive. You can stay up to date on all Java 9 related issues by going to our countdown site: java9countdown.xyz, and signing up for the newsletter.
| Reference: | Still Unsafe: The Major Bug in Java 6 That Turned into a Java 9 Feature from our JCG partner at the Takipi blog. |
I will download the books hopefully after I submit this form.