[native] Quarkus not able to parse GraalVM version in upcoming 21.1

[zakkak]

Describe 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

1. Grab GraalVM from https://github.com/graalvm/graalvm-ce-dev-builds/releases/tag/21.1.0-dev-20210330_0726
2. Build a Quarkus app or test with -Dnative and GRAALVM_HOME pointing to GraalVM 21.1.0-dev

[jaikiran]

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:

...

GRAALVM_VERSION="21.1.0-dev"
...
JAVA_VERSION="11.0.11"

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.

[jerboaa]

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.

The release file for Mandrel is just OpenJDK's release file, so this won't work, unfortunately.

$ /disk/graal/builds/mandrel-java11-21.0.0.0-Final/bin/native-image --version
GraalVM Version 21.0.0.0-Final (Mandrel Distribution) (Java Version 11.0.10+9)
$ cat /disk/graal/builds/mandrel-java11-21.0.0.0-Final/release 
IMPLEMENTOR="N/A"
IMPLEMENTOR_VERSION="18.9"
JAVA_VERSION="11.0.10"
JAVA_VERSION_DATE="2021-01-19"
MODULES="java.base java.compiler java.datatransfer java.xml java.prefs java.desktop java.instrument java.logging java.management java.security.sasl java.naming java.rmi java.management.rmi java.net.http java.scripting java.security.jgss java.transaction.xa java.sql java.sql.rowset java.xml.crypto java.se java.smartcardio jdk.accessibility jdk.internal.vm.ci jdk.management jdk.unsupported jdk.internal.vm.compiler jdk.aot jdk.internal.jvmstat jdk.attach jdk.charsets jdk.compiler jdk.crypto.ec jdk.crypto.cryptoki jdk.dynalink jdk.internal.ed jdk.editpad jdk.hotspot.agent jdk.httpserver jdk.internal.le jdk.internal.opt jdk.internal.vm.compiler.management jdk.jartool jdk.javadoc jdk.jcmd jdk.management.agent jdk.jconsole jdk.jdeps jdk.jdwp.agent jdk.jdi jdk.jfr jdk.jlink jdk.jshell jdk.jsobject jdk.jstatd jdk.localedata jdk.management.jfr jdk.naming.dns jdk.naming.ldap jdk.naming.rmi jdk.net jdk.pack jdk.rmic jdk.scripting.nashorn jdk.scripting.nashorn.shell jdk.sctp jdk.security.auth jdk.security.jgss jdk.unsupported.desktop jdk.xml.dom jdk.zipfs"
OS_ARCH="x86_64"
OS_NAME="Linux"
SOURCE=".:hg:405102e26a62+"

[jaikiran]

Hello @jerboaa, I haven't been following Mandrel development work, but I was under the impression that it was changes/enhancements/fixes on top of Graal VM (and not on top of vanilla OpenJDK Java). Isn't that the case? If so, perhaps it needs to follow similar constructs/semantics that Graal VM follows for generating this release file and maybe include a "MANDREL_VERSION" property?

[gsmet]

I don't know how complex it would be but I would also be in favor of what @jaikiran proposes (and adjust Mandrel if needed to have similar properties).

[zakkak]

I believe the following sentence is the best description of Mandrel I have seen so far.

Mandrel can best be described as a distribution of a regular OpenJDK with a specially packaged GraalVM native image.

Source: https://developers.redhat.com/blog/2020/06/05/mandrel-a-community-distribution-of-graalvm-for-the-red-hat-build-of-quarkus/

So to make it a bit more clear:
Mandrel is a distribution of vanilla/upstream OpenJDK with a specially packaged GraalVM native-image.

As such, unfortunately it doesn't seem to make sense to alter the release file (which is part of the OpenJDK and not native-image) to include GRAALVM_VERSION or MANDREL_VERSION.

[gsmet]

As such, unfortunately it doesn't seem to make sense to alter the release file (which is part of the OpenJDK and not native-image) to include GRAALVM_VERSION or MANDREL_VERSION.

Why? Having it there would make sense given you also package some GraalVM bits. I don't see why you're so reluctant to do that?

[jerboaa]

As such, unfortunately it doesn't seem to make sense to alter the release file (which is part of the OpenJDK and not native-image) to include GRAALVM_VERSION or MANDREL_VERSION.

Why? Having it there would make sense given you also package some GraalVM bits. I don't see why you're so reluctant to do that?

One reason would be that in the RPM case, that file is being owned by the java-11-openjdk-headless package and it's discouraged to change other package's files. Would adding a mandrel-release file work?

[jerboaa]

Also I think that Graal VM CE uses jlink's --release-info plugin (e.g. --release-info=add:GRAALVM_VERSION=21.1.0) to append to the release file. Mandrel doesn't do a custom runtime with jlink it uses plain OpenJDK.

[maxandersen]

Mandrel might see itself as custom openjdk build but the java version is the least interesting part for Quarkus - its the base version of graalvm parts that are relevant for native-image command.

relying on properties file inside a jdk distribution isn't really usable as we have no guarantee users have such setup.

why is it that native-image in mandrel can't just do the same as graalvm native-image does and we adjust quarkus to attempt parse with both patterns?

[jerboaa]

why is it that native-image in mandrel can't just do the same as graalvm native-image does and we adjust quarkus to attempt parse with both patterns?

I'm +1 to keeping with native-image --version logic.

We are looking to "align" with Graal VM for native-image --version via graalvm/mandrel#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.

[maxandersen]

so GraalVM 21.1.0 Java 11 CE (Java Version 11.0.11+5-jvmci-21.1-b02) becomes Mandrel 21.1.0 Java 11 (Java Version 11.0.11) ?

[zakkak]

I was thinking about native-image 21.1.0.0 Java 11 Mandrel Distribution (Java Version 11.0.10+9) for Mandrel's bash script and
native-image 21.1.0.0 Java 11 CE (Java Version 11.0.11+5-jvmci-21.1-b02) for GraalVM's bash script (which is not shipped with GraalVM CE).
This is discussed in graalvm/mandrel#230 so please refer there for more info and to propose alternatives.