[23.0.0] The `org.graalvm.truffle:truffle-api` JAR contains JDK-19 specific files which are compiled with JDK 20

[boris-petrov]

Describe GraalVM and your environment :

• GraalVM version or commit id if built from source: 23.0.0
• CE or EE: CE
• JDK version: 19
• OS and OS Version: Linux
• Architecture: amd64
• The output of java -Xinternalversion:

  OpenJDK 64-Bit Server VM (19.0.2+7) for linux-amd64 JRE (19.0.2+7), built on 2023-01-18T16:17:00Z by "builduser" with gcc 12.2.1 20230111

Have you verified this issue still happens when using the latest snapshot? No.

Describe the issue Running Graal's Truffle API on JDK 19 doesn't work. I get:

Suppressed: org.graalvm.polyglot.PolyglotException: java.lang.UnsupportedClassVersionError: com/oracle/truffle/api/impl/JDKAccessor has been compiled by a more recent version of the Java Runtime (class file version 64.0), this version of the Java Runtime only recognizes class file versions up to 63.0

Which is normal because the file META-INF/versions/19/com/oracle/truffle/api/impl/JDKAccessor.class in the org.graalvm.truffle:truffle-api JAR is compiled with JDK 20.

Code snippet or code repository that reproduces the issue Any code that uses Graal.

Steps to reproduce the issue Any code that uses Graal.

Expected behavior This file to be compiled with JDK-19 max.

Additional context This makes the Truffle API unusable on JDK-19.

[chumer]

This was quite some oversight. Thanks for the report. We test these days with 20 and 17. The fix likely be to bump the version for the JDKAccessor class to 20.

[boris-petrov]

You mean bump the directory name from META-INF/versions/19 to META-INF/versions/20? That would fix the issue, yes. I'm unsure why this version-specific class file is there at all.

Any chance for a quick-release to fix this? I'm not really sure how to workaround that unfortunately.

[chumer]

You could use JDK 20 or remove the folder from the jar. this is only used to detect loom usage atm.

[boris-petrov]

I can't use JDK 20 unfortunately because Gradle still doesn't support it (fully). As for removing the folder from the JAR... that's easier said than done when using build systems like Gradle. :smile: If there are no plans for a quick-release I'll try to think of something, thanks!

[chumer]

You can also use JDK 17 or 18. Sorry for the inconvenience. It can take a bit until the fix lands on Maven.

[boris-petrov]

No worries. Thanks for the great work and support!

[gilles-duboscq]

I think the issue comes from this code: https://github.com/graalvm/mx/blob/b35d493d0a802654dd0b6c2ee6d4834c14ebc38e/mx.py#L7757-L7777

I don't think we should ever use something else than compliance to set -target.

I'm not 100% sure yet how we should deal with javaPreviewNeeded here. Especially since if a class gets its minor java version set to 65535 for preview feature usage it can then only be used with a VM where the major version is an exact match.

/cc @dougxc

[dougxc]

Sorry, I don't know the right path forward here either.

[gilles-duboscq]

My recommendation in the short term would be to ensure javaPreviewNeeded is not used in anything we ship. If it's possible to remove in this current truffle case, then we can just push the problem to the next time we want to use preview features in something we ship.

[chumer]

We want to detect VirtualThreads and fail. If we bump to the next release e.g. 20, the detection will not work for 19.

[gilles-duboscq]

If the next release is for JDK 21 the question goes away. For a fix in the 23.0 branch, i think we should set the compliance of this project to JDK20, this will ensure that this code is only used on JDK 20+. JDK 19 is not supported anymore anyway upstream (Oracle or Open JDK).

[chumer]

ok.

[boris-petrov]

I believe this issue has been resolved in GraalVM 23.0.1. In it I see only version-specific files for JDK 20. Thanks all!