org.graalvm.sdk:graal-sdk 23.0.0 artifact no longer JDK 11 bytecode compatible

[jerboaa]

Not sure if this a native-image issue. Please transfer to where it's most appropriate.

Issue Description:

The org.graalvm.sdk:graal-sdk in version 23.0.0 from maven central is no longer consumable by projects compiling to target level 11 (for JDK 11 compatibility). That is, those projects would have to at least target JDK 17. This used to work with graal-sdk 22.3.x.

Steps to reproduce

1. git clone https://github.com/jerboaa/reproducers-graal.git && cd reproducers-graal/graal-23-jdk11-compliance-repro
2. mvn package

This fails with:

[INFO] -------------------------------------------------------------
[INFO] ------------------------------------------------------------------------
[INFO] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[INFO] Total time:  0.871 s
[INFO] Finished at: 2023-06-19T15:46:51+02:00
[INFO] ------------------------------------------------------------------------
[ERROR] Failed to execute goal org.apache.maven.plugins:maven-compiler-plugin:3.8.0:compile (default-compile) on project version: Compilation failure: Compilation failure: 
[ERROR] /home/sgehwolf/Documents/mandrel/bugs/upstream-graal/reproducers-graal/graal-23-jdk11-compliance-repro/src/main/java/version/TargetSub.java:[24,36] cannot access com.oracle.svm.core.annotate.Substitute
[ERROR]   bad class file: /home/sgehwolf/.m2/repository/org/graalvm/sdk/graal-sdk/23.0.0/graal-sdk-23.0.0.jar(/com/oracle/svm/core/annotate/Substitute.class)
[ERROR]     class file has wrong version 61.0, should be 55.0
[ERROR]     Please remove or make sure it appears in the correct subdirectory of the classpath.
[ERROR] /home/sgehwolf/Documents/mandrel/bugs/upstream-graal/reproducers-graal/graal-23-jdk11-compliance-repro/src/main/java/version/TargetSub.java:[25,36] cannot access com.oracle.svm.core.annotate.TargetClass
[ERROR]   bad class file: /home/sgehwolf/.m2/repository/org/graalvm/sdk/graal-sdk/23.0.0/graal-sdk-23.0.0.jar(/com/oracle/svm/core/annotate/TargetClass.class)
[ERROR]     class file has wrong version 61.0, should be 55.0
[ERROR]     Please remove or make sure it appears in the correct subdirectory of the classpath.
[ERROR] /home/sgehwolf/Documents/mandrel/bugs/upstream-graal/reproducers-graal/graal-23-jdk11-compliance-repro/src/main/java/version/TargetSub.java:[30,2] cannot find symbol
[ERROR]   symbol: class TargetClass
[ERROR] /home/sgehwolf/Documents/mandrel/bugs/upstream-graal/reproducers-graal/graal-23-jdk11-compliance-repro/src/main/java/version/TargetSub.java:[34,6] cannot find symbol
[ERROR]   symbol:   class Substitute
[ERROR]   location: class version.TargetSub

Additional info

The change which seems to have introduced this issue is:
#5838

Use case information

The use-case we'd have in mind is this. Be able to run the library with some older JDK, but still have the option to compile the library to native with latest GraalVM (23.0) currently. At the same time, avoid the need to depend on two GraalVM versions to support this. While this substitution example is contrived in the larger framework context those are sometimes needed in order to create leaner apps.

$ java -showversion -jar target/version.jar 
openjdk version "11.0.19" 2023-04-18
OpenJDK Runtime Environment (Red_Hat-11.0.19.0.7-2.fc37) (build 11.0.19+7)
OpenJDK 64-Bit Server VM (Red_Hat-11.0.19.0.7-2.fc37) (build 11.0.19+7, mixed mode, sharing)
Sub: Hello!
$ native-image --version
native-image 17.0.7 2023-04-18
GraalVM Runtime Environment GraalVM CE 17.0.7+7.1 (build 17.0.7+7-jvmci-23.0-b12)
Substrate VM GraalVM CE 17.0.7+7.1 (build 17.0.7+7, serial gc)
$ native-image -jar target/version.jar versions
$ ./versions 
TargetSub: Hello!

[jerboaa]

Would it be acceptable to compile with compliance level 11 for sdk of 23.0?

[gilles-duboscq]

GraalVM 22.3 was compatible with Java 11, while 23.0 is compatible with JDK 17 and 20.
Projects compiling to target level 11 should depend on graal-sdk 22.3.2.

[maxandersen]

here is the issue - this means graalvm can't add or change any of the annotations found in svm or the SDK.

Or rather you can - but then users with java 11 dependencies will be blocked to use graalvm.
In a few months that happens for Java 17 too - and even graalvm oracle VM cannot provide a release of this as the artifacts are in maven central.

The same will happen with all intermediate java releases.

So I'm fully grokking the need/want to have the JDK alignment but for these Annotation Jar's what is the technical requirement to force these to move to latest classfile format ?

[gilles-duboscq]

here is the issue - this means graalvm can't add or change any of the annotations found in svm or the SDK.

The SDK has always been developed in a backward-compatible way so I don't see how this is blocking anyone.

Regarding anything in the SVM jars, it's never been supported to depend on that and that indeed requires more complex maintenance for anything that depends on such classes.

GraalVM can add new annotations or other classes in the SDK if needed, it just needs to be done in a backward compatible way.
Renaming / removing annotation or other classes can be done but needs to happen over a longer period of time: first deprecating the old APIs (probably with the new forRemoval method) in one major release, and only later removing it.

If the concern is around com.oracle.svm.core.annotate specifically (which was moved from SVM to the SDK in 22.3) their current API status is a little bit ambiguous so maybe that's the issue. If that's where the confusion comes from, then we should indeed clarify the backward compatibility of those.

what is the technical requirement to force these to move to latest classfile format ?

i don't think it would make sense to facilitate depending on newer version of the SDK with older Java versions since anyway there would be no GraalVM version that you can use to leverage the newer features of the API. I would view it the same as "Why compile the Java 21 classes with the latest classfile format?".

[jerboaa]

I've updated the description with some use case info. Hope that makes it clearer.

[ansalond]

#6949 integrated the proposed patch: jerboaa@98069bb.
The changes will also be backported to the 23.0 release branch.

[jerboaa]

Thank you!

[LeifW]

I just want to use the graalvm polyglot library - specifically graalvm.js, on a regular JVM. Is support for JVMs older than 17 dropped in 23.0? I didn't see anything in the release notes about that.

[maxandersen]

Quarkus does not use that library from graalvm. Youll have ti check with graalvm which parts are supported or not on various jvms.

I Can just say that afaik everything was bumped to Java 17. This issue is about at least enable Java 11 compiled libraries to use native image SDK features that targets Java 17.

Heads up - Next Release of graalvm in september Will target Java 21.

[galderz]

I've just verified that the Maven artifacts for graal-sdk version 23.0.1 released a week ago fix this.

[galderz]

FYI I've created a Quarkus PR to upgrade to this version quarkusio/quarkus#35057

[LeifW]

I've verified graal-sdk 23.0.1 does not fix this issue. It still says the classfile version on org.graalvm.polyglot.Source is 61, meaning it requires Java 17 or later.

Using Java 11:

scala -classpath /home/leif/.cache/coursier/v1/https/repo1.maven.org/maven2/org/graalvm/sdk/graal-sdk/23.0.1/graal-sdk-23.0.1.jar                                           
Welcome to Scala 2.13.11-20230614-134106-e17bab0 (OpenJDK 64-Bit Server VM, Java 11.0.20.1).

scala> import org.graalvm.polyglot.Source
scala> classOf[Source]
java.lang.UnsupportedClassVersionError: org/graalvm/polyglot/Source has been compiled by a more recent version of the Java Runtime (class file version 61.0), this version of the Java Runtime only recognizes class file versions up to 55.0

[gilles-duboscq]

What is you use-case for using the 23.0 org.graalvm.polyglot API on java 11? The optimized runtime for this version only exists for Java 17 anyway.

[LeifW]

To run JavaScript scripts in an embedded interpreter on the JVM. I don't care about the JIT so much for that case. Nashorn is deprecated - that just leaves graaljs afaik as the only current option for running JavaScript on the JVM.

[gilles-duboscq]

That would imply that you also need a Graal JS implementation that still works on Java 11.
At the moment your best bet is probably js and polyglot 22.3.x.

/cc @woess, @chumer