[native] Quarkus not able to parse GraalVM version in upcoming 21.1
See original GitHub issueDescribe the bug
Quakus fails to parse the GraalVM version from native-image --version
in upcoming GraalVM 21.1.
This is because in the upcoming GraalVM the version is:
GraalVM Version 21.0.0 (Java Version 11.0.10+8-jvmci-21.0-b06)
while in previous versions it used to be:
GraalVM 21.1.0 Java 11 CE (Java Version 11.0.11+5-jvmci-21.1-b02)
Note the removal of “Version” and the addition of “Java 11 CE”.
Expected behavior
Quarkus should be able to get the version without any warning or error.
Actual behavior
Quarkus prints:
[io.quarkus.deployment.pkg.steps.NativeImageBuildStep] Unable to get GraalVM version from the native-image binary.
To Reproduce
- Grab GraalVM from https://github.com/graalvm/graalvm-ce-dev-builds/releases/tag/21.1.0-dev-20210330_0726
- Build a Quarkus app or test with
-Dnative
andGRAALVM_HOME
pointing to GraalVM 21.1.0-dev
Issue Analytics
- State:
- Created 2 years ago
- Comments:12 (12 by maintainers)
Top Results From Across the Web
Building a Native Executable - Quarkus
If you are building native executables for macOS, you should consider using Oracle GraalVM instead, because Mandrel does not currently target this platform....
Read more >Release Notes - GraalVM Enterprise Edition
Update the G1 GC version that is available in Native Image to JDK 19. ... Switched to a new parser generated from CPython's...
Read more >21.1.0 - GraalVM
GraalVM is a high-performance JDK distribution written for Java and other JVM languages, along with support for JavaScript, Ruby, Python, ...
Read more >Working with Random/SplittableRandom instances in ...
Working with Random/SplittableRandom instances in GraalVM and Mandrel native images. Last updated on 2022-03-01 13 min read. Introduction.
Read more >Release Notes for Red Hat build of Quarkus 2.2
5 introduces support for Java version 17. Java 17 is supported in JVM mode only. If you are building a Quarkus native executable,...
Read more >
Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free
Top Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
I’m +1 to keeping with
native-image --version
logic.We are looking to “align” with Graal VM for
native-image --version
via https://github.com/graalvm/mandrel/issues/230. but we cannot do it in full as a) Graal VM ships native image as native binary, Mandrel not (there is a risk shipping as native-image; rather than plain java app) b) Graal VM upstream would prefer not to call it Graal VM if it’s Mandrel (OpenJDK + native-image), not a native-image.Either way, something needs to change. It’s just a matter of coming to an agreement how quarkus parses the native image version and what the expected inputs are going to be for Mandrel/Graal.
Graal releases have for a long time included a
GRAALVM_HOME/release
file which is a properties file and contains important and useful information like the Graal VM version, Java version and various other things. For example, the one I have in my 21.1.0-dev currently has this:So I think it’s time to start parsing this file instead of relying on the
native-image --version
output which is less reliable due to changes like these.