Now you can see detailed data for individual Pods, Containers and Nodes in your Kubernetes
Oracle is planning to remove
sun.misc.Unsafe in Java 9. This is an absolute disaster in the making and has the potential to completely destroy the entire ecosystem around Java.
Almost every tool, infrastructure software, high performance library built using Java uses
sun.misc.Unsafe underneath. Here is a small list from the above linked document itself:
- Mockito / EasyMock / JMock / PowerMock
- Scala Specs
- Spring Framework
- Apache Kafka
- Apache Wink
- Apache Storm
- Apache Hadoop
- Apache Continuum
... and the list goes on and on.
However, Oracle seems bound on removing it for no reason. Here is a comment from their mailing list:
Let me be blunt -- sun.misc.Unsafe must die in a fire. It is -- wait
for it -- Unsafe. It must go. Ignore any kind of theoretical rope and
start the path to righteousness
This engineer hates the
Unsafe class for no real reason at all..
What Oracle should do
Unsafe class is a force of nature at this point. There is no point running from it. There is a clear need for the features of this class. There is also the fact that almost every java program uses it without even knowing about it since its used in so many popular Java libraries.
1. Document it and make it public
Instead of removing the class, Oracle should accept the reality and and make it a public API with good documentation and examples to go along.
Currently, without any specific documentation, one has to turn to StackOverflow posts or other random blog posts to understand how to work with
A big argument for removing
Unsafe is that it is too easy to shoot yourself in the foot with it. Having good, official documentation will prevent this.
2. Release new APIs alongside
Unsafe, Oracle should also release new, easier to work with APIs that achieve the same functionality. This is part of what is proposed in the above doc. However, this should not come at the cost of removal of
Unsafe. As newer software gets written, over time people will automatically stop using
Unsafe and prefer the newer APIs.
This is similar to how the new
DateTime APIs were introduced in Java 8 in the
java.time package. Their inclusion didn't mean that previous
DateTime APIs were completely removed or put behind a special flag. That would have been catastrophic.
What will (probably) actually happen
From the way things are heading, it seems Oracle will:
- Remove the
Unsafeclass for normal operation of JVM under Java 9
- Enable it only if a special flag is passed to the JVM.
This will result in absolute catastrophy!
Almost all Java programs, not just infrastructure software like Cassandra or Zookeeper, but also your web applications, will break, since the libraries they rely on probably uses
The flag to enable
Unsafewill become the default flag to launch the JVM henceforth, since without it your Java apps will break without notice.
Since most environments wont have this flag put in their JVM arguments by default, when they upgrade Java on their systems, their software will break.
Java will break its promise of backward compatibility. All libraries/infrastructure software will henceforth have 2 versions:
- Pre Java 9 - that uses
- Java 9 compatible - which does not use
- Adoption of Java 9 will slow to a crawl due to this, which would effect the entire Java ecosystem. The situation will be analogous to Python 2 and 3.
JVM screwups have happened before
Do you think this is too crazy and that Oracle would never make such a mistake? Actually it already did something like this with the bytecode verifier in Java 7.
Now is the time to spread awareness about this issue. Removal of
Unsafe from the JVM or putting it behind a special flag will result in absolute catastrophy.