[GR-69677] Restore JDK dependency to version 25

[graalvmbot]

We are aligning our development baseline back to JDK 25. Instead of the week-to-week tracking of JDK 26 early access builds, we will focus development on the JDK 25 LTS line for longer. This will reduce the maintenance cost related to pulling upstream changes frequently and will enable us to provide additional value for JDK 25 for longer.

Note that this change relies on JVMCI patches that are not (yet) backported to JDK 25. The LabsJDK source code used for the artifacts is located on the jdk25 branch in https://github.com/graalvm/labs-openjdk/tree/jdk25. The version used as of this PR can be found at https://github.com/graalvm/labs-openjdk/releases/tag/25%2B37-jvmci-b02.

[zapster]

cc @zakkak @simonis

[simonis]

@zapster will LabsJDK 25 still be synced with OpenJDK 25u?

[zapster]

@zapster will LabsJDK 25 still be synced with OpenJDK 25u?

Yes, we plan to update LabsJDK 25 regularly with that latest CPU releases once they are published.

[zakkak]

Thank you for the mention @zapster.

Yes, we plan to update LabsJDK 25 regularly with that latest CPU releases once they are published.

👍

The next question would be whether LabsJDK 25 is going to introduce new changes on top of OpenJDK 25u (which are no longer expected to make it to OpenJDK 25u). And the answer seems to be affirmative according to:

Note that this change relies on JVMCI patches that are not (yet) backported to JDK 25

This breaks Mandrel builds as we build based on OpenJDK. We (the Mandrel team) would like to discuss options on how to move forward in this new context.

[jerboaa]

Note that this change relies on JVMCI patches that are not (yet) backported to JDK 25

This breaks Mandrel builds as we build based on OpenJDK. We (the Mandrel team) would like to discuss options on how to move forward in this new context.

Unfortunately this brings us back to a time where certain LabsJDK changes needed to get merged in upstream OpenJDK to continue to support later GraalVM versions with Mandrel (even if it claims to be JDK 25-based; it's not). Either that, or stop using the later GraalVM versions.

While it would be a possibility for some contributors to use LabsJDK 25 it won't be an option for the Mandrel team. So this move is bound to further disintegrate the GraalVM native-image community who still care about Java. While I understand that this might be the right move for some it bears some risk to the greater open source GraalVM native-image community. Your mileage might vary.

[thomaswue]

@zakkak @jerboaa This is an intermediate step towards a solution that in our view will longer term make the overall maintenance simpler for everybody. We are working on turning the native image generator into a native image itself and in this way completely disentangling it from the HotSpot VM. Together with Project Crema (which enables the execution of arbitrary (including dynamically loaded) Java code in the context of native image (#11327), we will be able to create a GraalVM distribution that does no longer include the HotSpot VM. This reduces our reliance on upstream OpenJDK to only the Java class libraries and removes the dependency on JVMCI. To achieve the technical goals involved here, we will however need larger additions to JVMCI, which would possibly be not accepted in the upstream OpenJDK project. We will give detailed updates on the progress and road map related to these technical goals at the upcoming GraalVM Community Summit. We are also happy to discuss before that and will update the information available on GitHub about Project Crema as well as Project Terminus.

[adinn]

While it would be a possibility for some contributors to use LabsJDK 25 it won't be an option for the Mandrel team. So this move is bound to further disintegrate the GraalVM native-image community who still care about Java. While I understand that this might be the right move for some it bears some risk to the greater open source GraalVM native-image community. Your mileage might vary.

I'd like to expand on what @jerboaa is saying here, Mandrel releases have always been based on stock OpenJDK not Labs OpenJDK for a very clear reason:

• the Mandrel team is happy to support Quarkus apps built using a GraalVM Native product that is based on a standard OpenJDK release whose provenance and behaviour are sanctioned by the OpenJDK development, release and update process in which we are deeply involved.
• the Mandrel team is uncomfortable with having to support Quarkus apps built using a GraalVM Native product based on a modified OpenJDK release whose provenance and behaviour are defined by whatever contingencies lead the GraalVM team to make their own modifications and in whose development we have no involvement and little or no room for input.

The issue is that having to rely on Labs JDK effectively takes certain options out of our hands. It makes it harder for us to clearly and reliably define the behaviour of the JDK/JVM used for native deployments, foresee what the consequences of changes to JDK/JVM behaviour might mean for the behaviour of the deployed native app, and debug + fix any problems that might arise as a consequence of those changes. Effectively, we are at greater risk of encountering a situation where Quarkus apps might behave differently in Native vs Hotspot deployments and have a weaker chance of identifying why that has happened and remedying the disparity.

If this current issue continues -- including if it is fixed ad hoc but then continues to repeat with some variant incompatibility being introduced -- it will be hard for us not to treat it as a blocker for supporting Quarkus Native deployments. That clearly also brings into question our team's interest in continuing to contribute to the GraalVM project.

[thomaswue]

@adinn The changes to what is in upstream OpenJDK are limited to the JVMCI interface, which is unrelated to application behavior - and it is unclear whether that interface will continue to be maintained in upstream OpenJDK at all. Furthermore, this is only a temporary development step until we are no longer relying on this JVMCI interface implemented in HotSpot. We will not make changes to the parts that are shared with the HotSpot VM - i.e., the Java class libraries. Therefore, there is no additional risk in differing behavior. We are in general happy to verify that the behavior of Quarkus applications is identical.