|Dispel the serpents of doubt.|
[ I love mixing mythologies ]
No - from the man himself.
So stop worrying. Removing the performance benefits of sun.misc.Unsafe would fatally wound Java and other JVM languages. Whilst the Unsafe class itself is labile, the functionality it contains will remain.
Recently I was presenting at a Java technology internal conference for a client. Brian Goetz also presented. Aside from his usual, and basically incorrect, statements about the quality of the lambda implementation in Java 8 and that it takes linear time to scan a class path (sorry - but I have had to say that - please stop saying these things Brain, you make yourself look silly) he did say some really interesting, and reassuring stuff about Unsafe and project Panama.
What is the situation?
I am going to paraphrase from memory now so these are not Mr Goetz's words exactly but more what I took away from them:
- Unsafe came about as a 'dumping ground' for features which were required for performance reasons. Each feature in Unsafe is there to service other parts of the JDK.
- Over time the community learned to use it for other things apart from internal JDK classes.
- Now Oracle see Unsafe as an 'incubator' for new features.
- Features are/will-be tried out in Unsafe and then can migrate through two paths: First - they are rubbish and will be dropped. Second - they are great, the community loves them and so they will be solidified in to a main stream JDK class.
So, off heap access is going nowhere. However, in Java 9 the enhanced volatile access code in Unsafe is going to migrate to project Valhalla: http://openjdk.java.net/jeps/193.
BG also noted that the off heap access in Unsafe is going to stay there for Java 9. Whilst Panama is likely to completely replace Unsafe offheap eventually, that will not be in 9.
What does this mean for techniques like that I described in the Java Advent Calendar this year? Well, it means that in Java 9 they will just work. In Java 10 and above the low level calls might change. This makes it a good idea to hide those calls behind an abstraction. Now, that abstraction must be final and avoid virtual dispatch (ouch - stop shouting - yes I did mean that) but the high performance Java community are getting pretty good at that sort of thing these days. Once we have these abstractions in place we can migrate from 9 to 10 seamlessly.
Performance, Performance, Performance
There is a lot of concern about the idea 'Unsafe is going away'. At that conference mentioned, someone asked Brain Goetz something like 'can you promise the performance features of Unsafe are not going away'. He broadly did. That is important as it indicates sanity. We might think that Java is a 'Blue Collar Language' (what ever that means); but performance matters to blue collar coders just as much as white collar ones; actually, it probably matters more. Whilst researchers and theorists might love their functional definitions and declarative abstractions, people in day jobs selling yet another plastic action figure on Black Friday need one thing and one thing only - performance.
Seriously, whilst the chattering classes are flocking in their thousands to electric vehicles and champagne bars, the blue collar workers of the US are out buying 500hp pickup trucks and knocking back JD. The picture is much the same with vodka and golf GTIs in the UK.
Unsafe let Java properly break into performance territory. With technology like https://lmax-exchange.github.io/disruptor/ the concept of low latency Java was born [yes, it does use Unsafe - see here https://lmax-exchange.github.io/disruptor/docs/com/lmax/disruptor/util/Util.html ]. Azul Zing is breaking down the garbage collection barriers to huge memory sizes https://www.azul.com/products/zing/. Even super heavy lifting technology like COBOL is now running on the JVM https://www.youtube.com/watch?v=ZqjI3AZJhI8.
For Java to retain its number one place as the world's most popular programming language (http://nerds-central.blogspot.co.uk/2015/11/cobol-in-top-20-of-tiobe-what-does-this.html) it absolutely must get more performant, never less. Oracle certainly bang on about performance enough (https://blogs.oracle.com/thejavatutorials/entry/learn_more_about_performance_and) so I can only assume they are sane enough to realise that performance is absolutely key to the success of Java and therefore their ongoing sales of support and Java based products.