I disagree that the article is "misquoting via omission." The article claims that "this engineer hates the Unsafe class for no real reason at all." The full q

I disagree that the article is "misquoting via omission." The article claims that "this engineer hates the Unsafe class for no real reason at all." The full quote which you reproduced doesn't offer any reasons for hating unsafe. I also disagree that there is "no immediate risk." The end-of-life date for Java 8 is 2017, only 2 years from now. It can easily take a year or two to develop a product or internal tool. Would you sign off on a big new performance-critical project in Java, knowing that you might not be able to get the performance you want when these low-level APIs are removed? Java has had a bunch of security problems in the last few years, but most of them have not been related to Unsafe at all. For example CVE-2013-0422 related to Java webapps, CVE-2013-4444 related to Tomcat, and so on. There were a bunch of bugs for POODLE and other SSL issues, similar to many other programming languages. Perhaps you could argue that CVE-2013-0422 was related to Unsafe, but since in this case it was an internal standard library class, presumably Oracle would continue to give itself permission to use whatever unsafe-equivalent they come up with. If new APIs are needed are needed to replace uses of Unsafe, Oracle could simply add them gradually over time. This would be low-risk and easy for everyone. I can't see any reason why Unsafe needs to be "kill[ed]... as quickly as possible."