GraalVM EE is Dead, Long Live Oracle GraalVM

Historical background

To gradualy introduce everyone to the topic of today’s edition, it is appropriate to take a look at how the GraalVM licence has historically changed. After all, this ‘Holy Grail of virtual machines’ has long had two different variants – the first being the GraalVM Community Edition. This edition (often referred to as GraalVM CE) is probably the GraalVM you would be familiar with, forming the basis for at least the native images generated by most frameworks. At the same time there was something called GraalVM Enterprise Edition. However, don’t let the coincidence of nomenclature with even the likes of Jakarta EE fool you. While GraalVM CE can be used quite freely (the project itself is released under the GPL 2.0 licence, and the artefacts it generates under the licences of individual languages), GraalVM EE was a commercial project, released under the GraalVM Oracle Technology Network licence agreement. This means that a commercial Oracle subscription was required for its use in a production environment. And this can complicate adoption process for many companies.

The above is a joke, but there is a grain of truth in each one

If we were using Oracle Cloud – in principle we didn’t have to worry about anything, the licence was de facto ‘bundled’. However, if we were interested in using GraalVM in any other cloud environment, a licence fee was required, linked (at least at some stage, historically this may have changed) to the number of processors. For this reason, many teams abandoned the use of the Enterprise Edition, where the changes were not at all cosmetic and related to commercial support, as is usually the case with OpenJDK. Over the years, individual functionality has flowed between EE and CE, but the former has always featured better performance and some key featuers – such as support for G1.

This has been the case for years, however, at the end of last year, we saw the announcement of plans to integrate a large part of GraalVM CE into OpenJDK (which will involve licensing changes as well). What’s more, last week, news broke of the end of the GraalVM Enterprise Edition.

As described in A New GraalVM Release and New Free License!, GraalVM Enterprise Edition has been replaced by Oracle GraalVM, a new distribution with a new licensing model. The GraalVM Free Terms and Conditions (GFTC) licence for Early Adopter Versions – for that is what the new license is called – is quite a step forward. This is because, unlike the aforementioned provisions of GraalVM Enterprise Edition, Oracle GraalVM allows free use, both in development and in a commercial environment. As such, we can now use Oracle GraalVM when developing internal applications for our business. Here, however, some complexities come into play – for while the FAQ mentions free use in commercial applications, the license details mention that these must be “not provided for a fee”. This means, therefore, that for consulting work or when developing Software-as-a-Service solutions, I would strongly suggest consulting Oracle before use to ensure that your solution does not require the purchase of their subscription.

The naming has also been changed. Instead of GraalVM version 23.0, we now have GraalVM for JDK 17 and GraalVM for JDK 20. This is a change that was announced some time ago and is connected with the migration of parts of GraalVM CE to OpenJDK and the adoption of its release model. It is worth mentioning that it is not without reason that the license name contains the term “License for Early Adopter Versions”.

To quote the original FAQ:

Oracle will use the GFTC for GraalVM for JDK 17, GraalVM for JDK 20 and later releases. LTS releases, such as GraalVM for JDK 17, will receive updates under this license for one year after the release of the subsequent LTS. After the free use license period, Oracle intends to use the Oracle Technology Network License Agreement for GraalVM Enterprise Edition Including License for Early Adopter Version License, the same currently used for GraalVM Enterprise Edition 22 and earlier versions. Non-LTS releases such as GraalVM for JDK 20 will be available for their entire planned six months support life under the GFTC.

Despite these limitations, the introduction of Oracle GraalVM is a big step forward for the project. Especially with new functionalities also coming with the new release.

What’s new with Oracle GraalVM

In terms of new features, the most interesting from my perspective is the new profiler (unfortunately, not available in the CE version). To simplify, historically Native Images were characterized by faster start-ups than classic applications, however, their overall performance used to be worse in the long-running services. It’s because GraalVM could only optimise applications based on static data available at image build time, while the JIT compiler could additionally infer based on real production characteristics of the application. Now the developers of GraalVM have decided to harness machine learning. By using pre-learned machine learning models in the build process, even better optimizations were achieved. The technique enriches existing mechanizm called profile-guided optimisation (PGO).

It will be interesting to see if we would be able to fine-tune these kind of models on our own apps in the future.

In addition to changes in PGO, the new GraalVM introduces several other optimisation techniques, but the changes do not stop there. Native Image Bundles have been introduced – that is, the ability to easily share the configuration of a GraalVM build between developers. Another feature added in this release is the ability for Native Image to generate build reports. These reports provide information about the build environment, resources used and other analysis results. To further facilitate this, the sources of the Ideal Graph Visualizer (IGV) – a tool for analysing build graphs – have been opened, which can help to tackle performance issues.

In addition, support for AWT in Native Image has been extended to Linux, allowing even more GUI Java applications to be distributed via Native Image. And in terms of Developer Experience, debugging for Windows has been made easier, and management via JMX is now possible via the --enable-monitoring option. The release is also accompanied by a new website, including a list of libraries and frameworks that have been verified to work with Native Image. To conclude, the GraalVM JIT also now supports another Garbage Collector – ZGC.

All the details are in the aforementioned post A New GraalVM Release and New Free License!. And for those who like the video format, I recommend the webinar, which accompanies the news.

GraalVM isn’t just about Java

In addition, on the occasion of the Oracle GraalVM release, we received an additional publication What’s New in GraalVM Languages, reminding us that GraalVM goes far beyond the Java world. It focuses on changes for other languages supported by the Graal runtime.

GraalPy, a Python interpreter built on top of GraalVM, now also supports Windows. In addition, GraalPy introduces a new implementation of its Python C API, which improves performance and compatibility with some extensions. This can be seen in the updated metrics, which show performance improvements over CPython. The language and standard libraries have also been updated, and support for asyncio and plugins for virtualenv have been added.

The improvements don’t stop with Python, however. TruffleRuby and Node.js, in addition to runtime updates, got support for java.lang.BigInteger. Changes have also been made to the Polyglot Sandboxing policy to allow better control over permissions for ‘guest code’. Finally, improvements have been made to the Truffle DSL with the @GenerateInline annotation to suggest which code fragments should be inlined in generated binary.

If you’re curious about what such a GraalPy can be used for, you can find a video Using Python from Java with GraalVM on the official GraalVM YouTube channel. There was also a Empower your Spring-Applications with Python-Features on GraalVM session during the last Spring I/O, but unfortunately, the recording is not yet available. These, however, are gradually showing up, so if you don’t want to miss out, subscribe to the Spring/IO channel.

GraalVM EE is Dead, Long Live Oracle GraalVM – JVM Weekly vol. 139

Historical background