[GR-52835] Support OpenJDK versions in JVMCIVersionCheck

[graalvmbot]

This PR adds support to check OpenJDK versions in JVMCIVersionCheck.

Motivation

Up until now, we have always used a custom JDK build, also referred to as LabsJDK. A LabsJDK would identify as such via the -jvmci suffix:

$ java -version
openjdk version "23" 2024-09-17
OpenJDK Runtime Environment (build 23+17-jvmci-b01)
OpenJDK 64-Bit Server VM (build 23+17-jvmci-b01, mixed mode, sharing)

While building a custom JDK provides great flexibility, it is also an overhead, both in terms of time and computational resources. Especially for mainline development, where we update to the latest early access build every week, building our own JDK is a burden.

Thus, we are moving mainline development to use official early access builds of the JDK instead of building our own. This helps us move faster and is also more resource-friendly.

As a consequence, the JDK will no longer identify itself as a LabsJDK, because it is none:

java -version
openjdk version "23-ea" 2024-09-17
OpenJDK Runtime Environment (build 23-ea+17-1368)
OpenJDK 64-Bit Server VM (build 23-ea+17-1368, mixed mode, sharing)

Version Checking

Since various parts of GraalVM, such as the Graal compiler or Native Image, are tightly coupled with the JDK, a given revision of GraalVM only runs on a specific JDK version, namely the version that is specified in JVMCIVersionCheck#JVMCI_MIN_VERSIONS.

Both Graal and Native Image verify that the JDK version is not outdated and abort if it is. Up until now, however, the check was only performed when running a LabsJDK, i.e., a JDK with the -jvmci version suffix. When switching to official early access JDK builds, we will extend the check to OpenJDK versions, since the check greatly reduces the number of bug reports due to running on an outdated JDK version.

For regular users of GraalVM deployments, nothing changes because GraalVM will always ship with the correct JDK. However, extending the scope of the version check to OpenJDK impacts all users that run individual GraalVM components with a custom JDK. Ideally, it will help find wrong setups eagerly, so it can be seen as a usability improvement for these use cases. However, we cannot know all the different scenarios in which GraalVM is used with a custom JDK, so in case the version check complains but the user is certain that the custom JDK is in sync with the GraalVM sources, the check can be disabled by setting the JVMCI_VERSION_CHECK environment variable to ignore.

OpenJDK vs LabsJDK Version Checking Clarifications

If JVMCIVersionCheck#JVMCI_MIN_VERSIONS specifies a LabsJDK, for example 23+17-jvmci-b03, all OpenJDK versions based on the same build (in the example 23+17) or higher are considered recent enough, i.e., the version check is successful. So the JVMCI build number (b03 in the example) is ignored.

If an OpenJDK version is specified, e.g., 23+17, all JDKs (OpenJDKs, LabsJDKs, or any other JDK following the same version scheme) based on the same build are considered valid.

See JVMCIVersionCheckOpenJDKTest.java for more examples.

GraalVM Releases

The current plan is to use the official early access builds only during development. In the stabilization phase before a release and for the release itself, we will switch back to self-built LabsJDKs, as we did for previous releases.

Note: this PR does not yet moves mainline development to an official early access JDK build. It only adds the version checking capabilities in preparation for the move.

[zapster]

@jerboaa @zakkak please be aware of this change that might affect you and your team.

From all what I know about your usage of Graal, I believe that this will not cause any problems on your side. Still, if there are any questions or anything you want to discuss, please let me know.

[jerboaa]

@jerboaa @zakkak please be aware of this change that might affect you and your team.

From all what I know about your usage of Graal, I believe that this will not cause any problems on your side. Still, if there are any questions or anything you want to discuss, please let me know.

Thanks for the heads-up, @zapster! We'll keep monitoring the situation and agree it shouldn't cause problems on our side. We'll let you know if it does! ;-)