|GraalVM's Alignment With OpenJDK Signifies A New Era For Java|
|Written by Nikos Vaggalis|
|Thursday, 10 November 2022|
Oracle will be contributing GraalVM Community Edition Java Code to OpenJDK. There's a lot behind this simple statement. But before that, let's first look at what GraalVM actually does.
The recent flurry of interest in GraalVM started with a tweet that sparked excitement inside the Java community.
Oracle is contributing GraalVM Community Edition Java code to OpenJDK to more closely align the development of the GraalVM technologies with that of Java
Two technologies at play here; the well established OpenJDK and the newcomer, GraalVM.
At a very high level, GraalVM is a runtime split into two aspects; compile bytecode into native self-contained executables aka native images and run programs on the JVM in languages other than Java.
Per the first aspect, Native image is the executable binary file that contains your application, all its dependencies, and runtime components, allowing you to run your JVM based program on any supported configuration without the need for installing runtime or any setup. Native image is the easiest way to distribute your program and start it up faster.
Native images have several advantages over JVM interpreted applications:
Native images through AOT are important in bringing Java up to speed with the cloud era, even play a major role in it. For example, Spring Native Beta is now available, bringing a new way to deploy Spring applications by compiling Spring applications to native images using the GraalVM native-image compiler. Or the way that GraalVM enables Micronaut's Data project Ahead of Time (AoT) compilation to pre-compute queries for repository interfaces that are then executed by a thin, lightweight runtime layer. This requires:
Per the second aspect, Virtual Machines were invented in order to run programs in an independent way regardless of the platform and the underlying hardware. Examples are the . NET CLR, MoarVM, the modern virtual machine built for the Rakudo compiler implementing the Raku Programming Language, and, of course, the JVM. Initially the JVM was built in order to make Java portable across platforms by running bytecode coming out of the Java compiler. Soon enough other languages that could emit bytecode for the JVM came along, like Scala, Kotlin, Groovy or Clojure, therefore extending the JVM's application beyond Java.
This interoperability is happening through Truffle, the library for building programming language implementations expressed as self-optimizing Abstract Syntax Tree (AST) interpreters. In other words, it makes it easy to develop an interpreter for your custom programming language as the implementer has just to write a Java based AST interpreter for his language which subsequently gets JIT compiled by Graal into machine code. It's important to note that Graal can compile any language that is implemented as a Truffle interpreter.
Unfortunately Oracle's contributing GraalVM's code to OpenJDK does not include Truffle. Instead, Oracle plans to contribute the most applicable portions of the GraalVM just-in-time (JIT) compiler and Native Image, setting some things straight in the process. That is, GraalVM was being developed in parallel with the OpenJDK while maintaining a different license. The plan is now to align all the GraalVM technologies with Java both from a release perspective and from a licensing perspective. We are of course talking about the GraalVM CE edition. The Enterprise one will not be affected or merged with the OpenJDK project.
Aligning GraalVM releases with the JDK release model means that there will be:
In short GraalVM will have two releases a year, LTS and JEPs, while letting the community handle matters will speed up development of new features and instill trustworthiness to the longevity of the project.
The announcement also coincided with GraalVM's version 22. 3 release :
Also importantly carrying over from version 22.2 :
Thanks to several improvements in internal data structures, significantly less memory is required by Native Image when it builds a native executable.
The reduction of memory usage is particularly beneficial in memory-constrained environments, such as cloud services and GitHub Actions. Starting with release 22.2, the Native Image tool can successfully build many larger native executables with only 2 GB of Java heap.
So exciting times ahead for Java. GraalVM, AOT and the new release of JakartaEE 10 Core Profile firmly place Java in prime position for domination of the Cloud.
or email your comment to: firstname.lastname@example.org
|Last Updated ( Thursday, 10 November 2022 )|