In the previous post, we discussed the Shenandoah Garbage Collector and I mentioned some distributions to explicit if this garbage collector is supported or not.
There is an element of confusion when we talk about JDK, JVM, Hotspot… as these terms are often referenced but not always well described, and unfortunately sometimes not used correctly. The goal of this post is to try to clarify the terms and try to describe the current ecosystem.
We need to introduce three different concepts:
– JVM
– Implementation SDK
– Distribution SDK
The JVM
The Java SE has a set of specifications (Language + JVM) that is lead by Oracle. They decide how the language evolve.
What we call a JVM in the everyday language is usually an implementation of the JVM specification. The job of the JVM is to execute the Java bytecode (compiled .class files). In the JVM we will find the class loading, execution of the bytecode, the Just In Time compiler, the memory management and different garbage collectors….
There are three main JVM implementations:
- Hotspot : it is by far the dominant JVM, developed by Oracle
- J9 : an alternative JVM that was originally developed by Oracle. Its goal was to optimize the memory footprint, the startup performance to have a JVM better fitted for enterprise-scaled applications. It was later donated to the Eclipse Foundation and now exists under the name OpenJ9
- GraalVM : an alternative JVM developed by Oracle Labs with 2 main goals: replace the old Hotspot C2 compiler by a new compiler written in Java (Graal compler) so that it can be further developed and optimized and open the JVM to other languages (Python, Rust…). GraalVM is based on hotspot with some twists (different compiler + polyglot engine) rather than a full different JVM.
These 3 JVMs have a different profile and will fit different needs differently. The J9 JVM is known for consuming less memory but with the trade-off or lower throughputs, so it may be a good fit for containerized environments with less memory available.
The implementation JDK
To have a complete developer environment, we need to add on top of the JVM:
- The core Java libraries (
java.lang,java.util,java.io…) - The tooling to compile the code into bytecode (
javac,jar…) - The supporting infrastructure to ease the developer experience: troubleshooting looks like JFR or
jcmd, the JMX APIs, the certificate management tools like keytools or cacerts…
The implementation JDK provides an implementation for all the above and embeds the JVM. Each JVM has its own implementation JDK:
- Hotspot -> OpenJDK
- OpenJ9 JVM -> OpenJ9 JDK
- GraalVM JVM -> GraalVM JDK
As for the JVM, the JDKs provide different tooling options. For example, GraalVM is famous for its AOT and native image compilation capabilities that reduce the memory footprints of the application and speed up startup time.
The distribution JDK
Now that there is a project providing an implementation of the JDK, it still needs to be packaged, tuned, tested, supported and patched. That is what the distribution provides.
There are a lot of distributions: some require a paid license and provide enterprise reliability, guaranteed long term support, certified builds, some are open source. At the distribution level, some vendors decide to disable some features that they do not want to support (ZGC, Shenandoah GC, experimental JVM options), tune the heap flags differently or provide extra crypto algorithms, telemetry agents or diagnostic tools.
I hope this article helped to clarify the difference between an implementation of the SDK and a distribution. It highlighted that there are alternatives to the traditional HotSpot JVM / OpenJDK and we’ll try OpenJ9 and GraalVM in practice. That will be the subject of future articles.
Top comments (0)