Ok moving past the rhetoric of don't use internal classes, there is a value to sun.misc.Unsafe. It has been well known by Oracle for some time that it has to go away right.<p>Realise that those of us that do use it, are fully aware that it is a hack, and that we should be doing cleaner things. However know that those cleaner things _dont exist_; and that you, Dear application developer might not quite realise some of the shadow puppetry in making your favourite library work, please lay off the bile.<p>As others have said, this blog post stops short, the full quote is part of a very long and ongoing process to rid ourselves of Unsafe, replacing its majors usages with new API's.<p>This is a process Oracle started last year after the previous sun.reflect.Reflection.getCalleeClass mess. Yes, it no one should have been using an internal class. This method did not go away; it was made only available to the JVM internals, locked out from end users. The upshot of this was that, with no sane alternative, suddenly logging became between 2x and 100x more expensive where class names become involved. The JDK team somewhat back peddled on this change, and we are stuck here in a strange limbo land.<p>Was it right of Oracle to do this? Absolutely, everyone who goes down the internal package route is fully aware that these are open-state secrets, sure we all know them, but we should not be talking about them. Support for these damn things requires version to version checking, hideous reflection hacks and being prepared to read a lot of JVM source code for when bugs occur.<p>In light of all of this, and being the general level of awesome the JDK folks are they started a very direct community outreach to remove safely Unsafe. Last year they publicly asked people on the mailing list, and privately via email to do a survey (<a href="http://mail.openjdk.java.net/pipermail/core-libs-dev/2014-January/024650.html" rel="nofollow">http://mail.openjdk.java.net/pipermail/core-libs-dev/2014-Ja...</a>) on usages of Unsafe. I know this because I got an email from Paul Sandoz asking me to comment on Unsafe abusages.
Out of previous thinking from the JDK folks, as well as from the aforementioned survey, we have a bunch of JEP's for improving things regarding Unsafe.<p>Where things have gone slightly sideways is that we have, currently no unified working group to deal with these changes. What this document is, is a proposal to make a working group, focused on getting the right changes into the JVM. In the same ways as Project Jigsaw is for modularising the JVM (and is indirectly responsible for removing Unsafe), or the MLVM project handled making the VM better support other languages.<p>Unsafe is dead, long live Unsafe! I fully expect that we will achieve the right changes in during Java 9 to allow those of us that need to break the rules, to do it in a supported fashion.
I am _looking_ forward to the day when I can do setMemory or getAndSetInt via a supported API, and not one where I have to know the words Unsafe.theUnsafe. The above is a storm in a teacup, its open-source democracy at work.