“We’ll still have a little fun with Unsafe, presumably until Java 11”
Mark Reinhold has proposed a compromising solution for the treatment of the Unsafe class in Java 9. To find out exactly what this compromise will mean, and whether it can really dispel all doubts, we’ve enlisted the help of Hazelcast’s Christoph Engelbert.
JAXenter: Mark Reinhold has delivered a roadmap for the treatment of internal APIs in Java 9, via the OpenJDK mailing list. What does this entail?
Christoph Engelbert: Private APIs, for which there is already an alternative in Java 8, will be removed in Java 9. However, this doesn’t apply to a lot of private APIs as far as I know. Most APIs that fall into this category are probably rarely used.
Private APIs that have no alternative in Java 9 will continue to be available as before. The new scope “module” in Jigsaw will not be used to hide the packages.
Private APIs that have an alternative in Java 9 will be marked as deprecated and removed come Java 10 or hidden (Mark Reinhold affectionately calls it “encapsulated”).
sun.misc.Unsafe could perhaps hold a viable alternative and would thus be marked as deprecated by Java 10. We’ll still have a little fun with Unsafe, presumably until Java 11. But I’d like to encourage developers to adapt their frameworks and libraries as soon as possible and switch to the public alternatives when they’re available to avoid a renewed escalation of the situation in the future!
What does this mean for the much-discussed Unsafe API?
As already mentioned, sun.misc.Unsafe will likely fall into the second category. This means that in Java 9 nothing will change, except that Unsafe will get marked as deprecated. The package should still be exported and all previous applications would run as usual – at least, that’s my understanding. I don’t think VarHandles can be seen as a real alternative, definitely not in its current stage of development. Too many use cases are not yet covered, and this pounding of it by force would be fatal.
What is your personal opinion – has a good compromise been reached?
I think that not only is this a good compromise, it’s exactly what we’ve asked for –a clear migration path with the possibility of adapting a version of time systems and applications.
What happens now?
We, meaning Hazelcast and I, and many others will help to set up the use cases and test implementations corresponding to benefits and speed. Personally, I’m working intensively with just VarHandles, collecting information and testing my own implementations.
I think the right course is set, but Jigsaw may still bring a lot of other new problems (for example, the modified URL scheme by modules and the like) – but at least this issue looks to be solved.