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:

• Almost instant startup time
• Optimized resource consumption and smaller static footprint
• Does not require JVM for execution

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:

• No runtime model - Spring Data maintains a runtime meta-model that uses reflection to model relationships between entities. This model consumes significant memory and memory requirements grow as your application size grows. The problem is worse when combined with Hibernate which maintains its own meta-model as you end up with duplicate meta-models.
  
  
• No query translation - Spring Data uses regular expressions and pattern matching in combination with runtime generated proxies to translate a method definition on a Java interface into a query at runtime. No such runtime translation exists in Micronaut Data and this work is carried out by the Micronaut compiler at compilation time.
  
  
• No Reflection or Runtime Proxies - Micronaut Data uses no reflection or runtime proxies, resulting in better performance, smaller stack traces and reduced memory consumption due to a complete lack of reflection caches (Note that the backing implementation, for example Hibernate, may use reflection).
  
  
• Type Safety - Micronaut Data will actively check at compile time that a repository method can be implemented and fail compilation if it cannot.

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.

That still wasn't enough since nowadays a computing problem can sometimes be solved by combining features or libraries found amongst a multitude of languages. GraalVM is the attempt to bring languages that were never designed to work with the JVM together under one roof. We are talking about dynamic languages like Javascript, Python, Ruby as well as static ones like C/C++, Rust, Swift and Fortran.

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:

• Support for one Java SE Platform Specification per release
  
  
• Two feature releases per year
  
  
• Four predictable, quarterly Critical Patch Updates annually
  
  
• A Long-Term Support Release every two years

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 :

• GraalVM 22.3 is released for JDK 11, 17, and 19, planning to retire JDK 11 support in GraalVM 23.0
  
  
• A new way to download by one-line command, as simple as
  bash <(curl -sL https://get.graalvm.org/jdk)
  
  
• As of Java 18, you can use the jwebserver tool, a minimal HTTP server for prototyping, testing, and debugging. GraalVM JDK 19 now allows you do to just that, and even compile jwebserver into a native application
  
  
• Native Image monitoring
  
  
• GraalVM Native Build Tools
  
  
• New Native Image API

and more.

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.

More Information

Official announcement

Related Articles

Compile Spring Applications To Native Images With Spring Native

GraalVM Under The Covers

Making GraalVM-Based Executables Easy

TornadoVM Makes It Possible To Run Java on GPUs and FPGAs

Jakarta EE 10 - A New Era For Java On The Cloud

Micronaut 3. 2 Released for More Performant Microservices

To be informed about new articles on I Programmer, sign up for our weekly newsletter, subscribe to the RSS feed and follow us on Twitter, Facebook or Linkedin.

Comments

Make a Comment or View Existing Comments Using Disqus

or email your comment to: comments@i-programmer.info