Is GraalVM Free for production use?
If you’re super short on time and just want to know if you can use GraalVM in production:
Executive Summary: You can use GraalVM in production for 4 years after its LTS release. Be prepared to spend the fourth year upgrading your existing system to the next version of GraalVM.
Read on for details
Edit Jul 19, 2023: Thomas Wuerthinger tweeted some corrections at me. I thank him for them. My corrections are appended to this article.
What is GraalVM?
I’m skipping all boilerplate about GraalVM, OpenJDK etc. Google will do a better job explaining than I could.
Last month, Oracle announced their new license for GraalVM, the GFTC. While not a Free Software License, as defined by the Free Software Foundation, it allows most of the freedoms for a limited time period.
GraalVM will be released at the same cadence as OpenJDK. It will match the OpenJDK’s LTS and Short Term Support releases. GraalVM’s LTS Support is for 4 years and STS support is for 6 months.
I’ve illustrated the support below.
Every row is a specific version of GraalVM. Every column is a 6 month period. To safely run on production you want to be in the green area. You will have to shift your used version to a lower row to ensure you’re using an available and supported version. Naturally, the larger the intersection of green columns, the more time you have to plan and switch versions¹. For instance, if you’re on Graal 21, then you have between Mar ’26 and Mar ’27 to migrate to Graal 27.
In Oracle’s words: “Free releases and updates for versions Oracle designates as an LTS release, such as Oracle GraalVM for JDK 17, will continue for one full year after the next LTS release. This means Oracle intends to provide Oracle GraalVM for JDK 17 under the GFTC until one year after the release of Oracle GraalVM for JDK 21.”
Comparison to OpenJDK
Oracle also offers similar support for the OpenJDK under similar licensing terms. However, the crucial difference in the case of the OpenJDK is market offerings. Several companies offer Free versions of the OpenJDK with security patches for a longer time period. This is illustrated below:
IBM and Azul which also offer OpenJDK are not shown because I couldn’t find their end-of-support urls.
The Engineering Manager’s headache: Should I use GraalVM?
I don’t know the size of your engineering team or their bandwidth so my answers here should be considered a guide to thinking rather than prescriptive.
As things stand today, with Oracle as the sole GraalVM provider [but see amendments below], using GraalVM means you can use the LTS version for 4 years with the last year available to migrate to the next version. If you can ensure you engineering teams can migrate from the old to the new, you are fine.
- Make sure you have lots and lots of automation tests against your existing system so you can assert behavior against the new one.
- Make sure you really need GraalVM. GraalVM offers many benefits. Make sure you can justify it before you embark on that journey.
Note that the licensing terms with GraalVM are different from those of OpenJDK. In the case of OpenJDK the risk you open yourself to is security compliance (which you might overcome using other means).
[Disclaimer: I am not a lawyer. These are my interpretations. I believe they are true and am writing these in the hope they are useful. But if you want legal advice meet a lawyer.]
- Amazon reference: https://aws.amazon.com/corretto/faqs/
- Microsoft reference: https://learn.microsoft.com/en-us/java/openjdk/support#release-and-servicing-roadmap
Amendments
- RedHat offers an alternative GraalVM implementation called Mandrel. It appears to be specialized towards the Quarkus framework. See their blog post on justification for the same.
- Bellsoft offers Liberca with goals similar to RedHat’s Mandrel
- I removed the section on violation of contract because that seems not to be the case. It could be that I confused duration of receiving support with term of license end. The current document, updated June 2023, says nothing about a duration. “Additionally, customers using Native Image need to be prepared to upgrade to the most recent version in the event that Oracle has to make any changes to the technology in order to remain compatible with the Java specifications. Backports of fixes may also be limited.”
- Thomas Wuerthinger’s tweet
