Add support for JDK20 and retire JDK11 support

[fniephaus]

TL;DR

We add support for JDK20 in the next release (GraalVM for JDK17/JDK20) and stop shipping JDK11 builds.

Goals

The majority of GraalVM users like to use the latest JDK features. While experimental GraalVM JDK19 builds are shipping with the 22.3 release (see #4957), we plan to add JDK20 support in the 23.0 release. At the same time, we are going to drop JDK11 builds. This will allow us to remove JDK11-specific code from our code base, so that GraalVM can continue to move fast and stay up-to-date with the latest JDK releases.

Non-Goals

• Drop support for JDK17
• Keep maintaining support for JDK11

[helloguo]

In terms of "remove JDK11-specific code from our code base", do you have any timeline when the Java 11 related code will be removed?

[helloguo]

Just some context: we use GraalVM CE Java 8 and Java 11 at Meta. It would be great if the community keeps the Java 11 related code in the codebase.

[wirthi]

Hi @helloguo

for future releases of GraalVM (e.g. 23.0) we will concentrate on the newest versions of Java, so definitely no Java 11 support there. That is what this ticket is about.

I suppose you are working with one of the existing release trains (22.3.x, 21.3.x). The CE releases have limited support, I believe it is 18 12 months typically. If you need to use the older java versions that are still supported in those release trains, for longer than that period, then you need to go to the EE version.

Christian

[sgammon]

Just some context: we use GraalVM CE Java 8 and Java 11 at Meta. It would be great if the community keeps the Java 11 related code in the codebase.

It would be great if Meta would not hold the entire community back just because it doesn't want to license EE

[plokhotnyuk]

Despite that dropping of support for JDK17 is not the goal I see that latest dev builds have only JDK20 support.

Will the release have the support any LTS version for Java?

[fniephaus]

Will the release have the support any LTS version for Java?

Yes, we'll also ship JDK17-based builds of GraalVM in the next release. We are aware that those are currently missing in the dev builds and we are working on bringing them back.

[fniephaus]

JDK17-based GraalVM dev builds are available again.

[plokhotnyuk]

JDK17-based GraalVM dev builds are available again.

Thanks you all for the amazing work!

Just launched with them the set of 1.5K+ benchmarks for Scala JSON parsers

The results of the previous run with GraalVM CE Java19 23-dev and other JVMs are here: 1 thread and 16 threads

[anbusampath]

JDK17-based GraalVM dev builds are available again.

is that mean in March/April, Do we see GraalVM for JDK 17 and GraalVM for JDK 20 releases?

[fniephaus]

@anbusampath yes, that's correct.

[fniephaus]

JDK20 builds have landed about a week ago and JDK17 are back online, so we can consider this done for the next release.

[mjordan79]

So basically this means GraalVM has no use in enterprise applications, claiming that "kid" developers like using latest features for their toys. JDK11 support ends 30 September 2026, while GraalVM has already removed it.
Any chance GraalVM will also support adult developers besides the kindergarden? You know, those who have to support real customers.

Thanks.

[eregon]

@mjordan79 As you can see on https://www.oracle.com/downloads/graalvm-downloads.html there are Oracle GraalVM Enterprise Edition 20, 21, 22 still supporting Java 11.

[adinn]

@mjordan79 Could you try to rein in your vitriol. It doesn't look very professional to accuse others of being kindergarten developers and then proceed to throw your own toys out of the pram.

Let's put your request into perspective. The amount of work involved in maintaining OpenJDK JDK11 until 2026 is enormous. The team involved in doing so includes hundreds of developers, QE staff and release engineers from a range of companies, including the likes of Oracle, Red Hat, Amazon, Google, Azul, Bell Soft, Microsoft, etc -- not to mention some individuals contributing in their own time. Granted most of that team also maintains JDK8 (until 2030!), JDK17 and JDK21. Nevertheless, it is a very large stretch to keep JDK11 alive and, most importantly, requires attention from some of the most experienced JDK developers, especially the security team.

Even at the current scale, the OpenJDK maintenance project is a long way from being overstaffed. The large cost involved is met by the very large market for OpenJDK support from a broadly established and long term deployed base. Like all open source efforts, the maintenance team grew to meet those market demands and also to meet the large backlog of deployed applications that rely on legacy releases to continue operation.

Now, consider GraalVM. It is a new product with a small but fast growing market and likewise small but fast growing suite of deployments. Compared to OpenJDK, the smaller size of the current market and the smaller community involved in development and maintenance means that GraalVM is still developing a revenue stream to support current growth. Much as GraalVM can rely on and profit from some of the effort expended on OpenJDK it still comprises a very large and complex code base that is independent of OpenJDK. Development has to concentrate on implementing the capabilities of the latest JDK releases -- if that is not done then GraalVM really will have no future. Not surprisingly the conclusion is that GraalVM cannot currently afford to maintain legacy GraalVM releases for all existing OpenJDK LTS releases on a life cycle comparable to OpenJDK. Those who wish to develop on GraalVM will simply have to upgrade their deployments more frequently than on OpenJDK while the market for native Java is growing.

The answer to this problem, as with any open source project, is for those who wish to profit from using GraalVM to plow some of their profits back into maintenance as they grow a market for products that depend on GraalVM. Red Hat has been nurturing a user community for Quarkus Native running on GraalVM and is on the cusp of providing paid support. As a result we have committed resources to maintaining JDK17 support for our Mandrel releases, as we expect to do for JDK21. You are free to pitch in likewise and your help would be welcome.

I hope that is an adult enough argument for you to appreciate.

[mjordan79]

@mjordan79 Could you try to rein in your vitriol. It doesn't look very professional to accuse others of being kindergarten developers and then proceed to throw your own toys out of the pram.

Let's put your request into perspective. The amount of work involved in maintaining OpenJDK JDK11 until 2026 is enormous. The team involved in doing so includes hundreds of developers, QE staff and release engineers from a range of companies, including the likes of Oracle, Red Hat, Amazon, Google, Azul, Bell Soft, Microsoft, etc -- not to mention some individuals contributing in their own time. Granted most of that team also maintains JDK8 (until 2030!), JDK17 and JDK21. Nevertheless, it is a very large stretch to keep JDK11 alive and, most importantly, requires attention from some of the most experienced JDK developers, especially the security team.

Even at the current scale, the OpenJDK maintenance project is a long way from being overstaffed. The large cost involved is met by the very large market for OpenJDK support from a broadly established and long term deployed base. Like all open source efforts, the maintenance team grew to meet those market demands and also to meet the large backlog of deployed applications that rely on legacy releases to continue operation.

Now, consider GraalVM. It is a new product with a small but fast growing market and likewise small but fast growing suite of deployments. Compared to OpenJDK, the smaller size of the current market and the smaller community involved in development and maintenance means that GraalVM is still developing a revenue stream to support current growth. Much as GraalVM can rely on and profit from some of the effort expended on OpenJDK it still comprises a very large and complex code base that is independent of OpenJDK. Development has to concentrate on implementing the capabilities of the latest JDK releases -- if that is not done then GraalVM really will have no future. Not surprisingly the conclusion is that GraalVM cannot currently afford to maintain legacy GraalVM releases for all existing OpenJDK LTS releases on a life cycle comparable to OpenJDK. Those who wish to develop on GraalVM will simply have to upgrade their deployments more frequently than on OpenJDK while the market for native Java is growing.

The answer to this problem, as with any open source project, is for those who wish to profit from using GraalVM to plow some of their profits back into maintenance as they grow a market for products that depend on GraalVM. Red Hat has been nurturing a user community for Quarkus Native running on GraalVM and is on the cusp of providing paid support. As a result we have committed resources to maintaining JDK17 support for our Mandrel releases, as we expect to do for JDK21. You are free to pitch in likewise and your help would be welcome.

I hope that is an adult enough argument for you to appreciate.

Thank you very much for the answer, this is a much more comprehensible explanation than just claiming "developers like to use the latest features so let's remove the old stuff". I was in the process of evaluating the feasibility of GraalVM on existing customers with existing contracts that we cannot change, so, for now, the enterprise edition wouldn't be an option. Good to know at least we have an option for the future.