Spoiler: no

As previously reported on Voxxed, with the newest version of Java (launching in September 2016), there are a few uncharacteristic breaking changes. These will centre on tooling and internal APIs and should allow the platform to cast aside code which relies on “deprecated, removed, unsupported, internal or unspecified functionality.”

Thanks to the open nature of Java’s evolutionary process, developers have plenty of time to acquaint themselves with the new landscape coming in version 9. If you’re concerned, you can find an ongoing list of potential pitfalls on the official Wiki Outreach page and test the robustness of your code. However, one developer has issued a stark warning that this might not be enough.

In a blog post published this Monday,  Prashant Deva labelled Oracle’s plan to either remove or at least  hide by default sun.misc.Unsafean absolute disaster in the making” and, he speculates, something that could potentially “completely destroy the entire ecosystem around Java.”

Deva’s claim is based on the argument that the majority of tools, infrastructure software and high performance libraries are – in spite of the warnings – layered over Unsafe. This includes widely used tools like like Cassandra, Netty, Akka, Grails, and Neo4j. For Deva, Oracle “seems bound” on removing .Unsafe for no reason other than the whim of a few engineers.

Although it might sound like the California giant is effectively pulling the rug out from the Java ecosystem apropos of nothing, it’s worth bearing in mind that the use of Unsafe has been something that’s long been discouraged as risky business.

Akin to Microsoft’s CLR, the feature provides low level access to memory and processor features for JVM developers. However, as clearly stated in official Oracle documentation, any sun.* packages are not included in Oracle’s supported, public interface, and as such, cannot be guaranteed to work on all Java compatible platforms. Moreover, Oracle write, even if you are willing to run only on Oracle’s implementation of the JDK, “you run the risk of a new version of the implementation breaking your program.”

In this case, given Oracle’s duty to maintain the Java platform API and ensure prime functionality, it seems entirely reasonable for them to remove this problematic feature. With Java 9, Mark Reinhold and Co. are looking to amp up performance and security, and sweep out some of the detritus from the past in the process. Whilst this might cause some glitches, ultimately this is a move that is intended to benefit Java users in the long term.

Nevertheless, given just how widely unsafe has proliferated across the Javasphere, you can understand Deva’s disappointment. In an interview with InfoQ last week, Kirk Pepperdine gave a nice summary of the problem;

“Do we need to get rid of Unsafe? Yes! Do we need to keep Unsafe? Yes.”

The challenge now will be to port code using .Unsafe into the folds of the JDK proper, whilst ensure that anything that absolutely relies on the feature is not left totally adrift.

Will Removal of .Unsafe Trigger Javapocalypse?

About The Author
- Editor of Voxxed.com, focusing on all things Java, JVM, cloud-y, methodical, future-fantastic, and everything in between. Got a piece of news, article or tutorial you'd like to share with your fellow Voxxians? Drop us a line at info@voxxed.com

1 Comment

  • pron

    I really don’t understand this panic. The Unsafe issue has been known for a long time, Oracle conducted a survey on the matter a while back, and steps have been taken to address it. Java 9 will allow the continued use of Unsafe with a command-line flag, while the expert group assembled to come up with a public API as an alternative for Unsafe completes its work. This matter is well known and is being handled responsibly. The recent panic has been started by people who are apparently not familiar with the subject. Everybody relax.

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>