days
-1
-2
hours
-1
-4
minutes
0
-9
seconds
0
-5
search
Solution in sight?

Ditching of Java’s Unsafe reaches “pragmatic compromise”

Natali Vlatko
Hands image via Shutterstock

Oracle’s Mark Reinhold has delivered a solution of sorts to the debacle that is Java’s Unsafe class. In a proposal shared via the OpenJDK mailing list, the majority of the JDK’s internal APIs would be encapsulated as part of the overall modularisation effort for Java 9.

The ongoing debate about the removal of the Unsafe class in Java 9 has finally reached a somewhat amicable result, with Mark Reinhold of Oracle proposing to encapsulate most of the JDK’s internal APIs within the modules that define and use them.

Reinhold’s message was broadcast via the OpenJDK mailing list, where he suggested that encapsulating most of the JDK’s internal APIs (including sun.misc.Unsafe) would, by default, render them inaccessible to code outside the JDK.

This change will improve the integrity of the platform, since many of these internal APIs define privileged, security-sensitive operations. In the long run it will also reduce the costs borne by the maintainers of the JDK itself and by the maintainers of libraries and applications that, knowingly or not, make use of these non-standard, unstable, and unsupported internal APIs.

Acknowledging that a lot of popular libraries use sun.misc.Unsafe to invoke methods practically impossible to execute outside of the JDK, Reinhold’s proposition was met with agreement and relief that Oracle was not only acknowledging the issue, but also listening to the community in bringing about a solution.

Prominent Java figures like Christoph Engelbert, Martijn Verburg and Richard Warburton all voiced their approval of the plan, with Warburton glad to hear that this “pragmatic compromise” was being adopted.

SEE ALSO: Hazelcast on Unsafe – “The biggest problem is that it was available for so long”

Reinhold’s proposition also highlighted how users should treat critical APIs, like Unsafe, for the future adoption of Java 9:

  • If it has a supported replacement in JDK 8 then we will encapsulate it in JDK 9;
  • If it does not have a supported replacement in JDK 8 then we will not encapsulate it in JDK 9, so that it remains accessible to outside code;
  • If it has a supported replacement in JDK 9 then we will deprecate it in JDK 9 and encapsulate it, or possibly even remove it, in JDK 10.

Warburton was pleased to see that existing projects currently making use of unsupported internal APIs wouldn’t be affected in the meantime. A list of the proposed critical internal APIs to remain accessible come JDK 9 are available in JEP 260. It should be noted that the list won’t itself propose replacements for any internal APIs; that work will be covered by separate JEPs and, where appropriate, JSRs.

To suggest additions to the list, Reinhold has asked for them to be supported by real-world use cases and “estimates of developer and end-user impact”. Engelbert is currently in the process of putting together his own list of use cases with a gap analysis that revolves primarily around sun.misc.Unsafe.

He has also suggested that sun.reflect.ReflectionFactory, used by Objenesis, might be another class to add to the critical internal API agenda.

Author
Natali Vlatko
An Australian who calls Berlin home, via a two year love affair with Singapore. Natali was an Editorial Assistant for JAXenter.com (S&S Media Group).

Leave a Reply

Be the First to Comment!

avatar
400
  Subscribe  
Notify of