Determine how native-image --version should look like after the upstream version change

[jerboaa]

Description

Before we go ahead and use the new mandrel version output in Quarkus, we should define what the new version output should look like.

For a recent Mandrel build from GraalVM master with JDK 20.0.1-dev build (no java.vendor.version set) we get this:

native-image --version
native-image 20.0.1-internal 2023-04-18
OpenJDK Runtime Environment null (build 20.0.1-internal-adhoc.sgehwolf.jdk20u)
OpenJDK 64-Bit Server VM null (build 20.0.1-internal-adhoc.sgehwolf.jdk20u, mixed mode)

Or for a build with java.vendor.version property set it looks like this:

$ native-image --version
native-image 17.0.6 2023-01-17
OpenJDK Runtime Environment (Red_Hat-17.0.6.0.10-1.fc37) (build 17.0.6+10)
OpenJDK 64-Bit Server VM (Red_Hat-17.0.6.0.10-1.fc37) (build 17.0.6+10, mixed mode)

Which basically tells us everything about the JDK version, but nothing about the GraalVM code level. Note that Mandrel doesn't change OpenJDK, so the OpenJDK version info is less useful. This makes only sense if the whole native image code base would be part of OpenJDK itself, which it currently isn't.

Before the version change

GraalVM CE

$ native-image --version
GraalVM 22.3.0-dev Java 17 CE (Java Version 17.0.4+7-jvmci-22.3-b02)

Mandrel

$ native-image --version
native-image 22.3.1.0-Final Mandrel Distribution (Java Version 17.0.6+10)

After the version change

GraalVM CE

native-image 20 2023-03-21
GraalVM Runtime Environment GraalVM CE (build 20+34-jvmci-23.0-b10)
Substrate VM GraalVM CE (build 20+34, serial gc)

Mandrel

Insert your desired output here

[jerboaa]

/cc @zakkak @galderz @Karm @maxandersen

[jerboaa]

Also note that for mandrel we generally don't build the launcher as a native image, but keep the bash launcher. That has an effect on the version output too.

[jerboaa]

With oracle#6321 I'm proposing this (bash launcher):

$ native-image --version
native-image 17.0.6 2023-01-17
OpenJDK Runtime Environment Mandrel-23.0.0-dev (build 17.0.6+10)
OpenJDK 64-Bit Server VM Mandrel-23.0.0-dev (build 17.0.6+10, mixed mode)

Which changes to this if compiled to native (with --macro:native-image-launcher):

$ native-image --version
native-image 17.0.6 2023-01-17
GraalVM Runtime Environment Mandrel-23.0.0-dev (build 17.0.6+10)
Substrate VM Mandrel-23.0.0-dev (build 17.0.6+10, serial gc)

That should be good enough. Thoughts?

[jerboaa]

These two PRs implement the above proposal for mandrel:

1. mandrel-packaging: Adjust build scripts for new version scheme mandrel-packaging#328
2. upstream graal: [GR-44722] Make vendor version adjustable at build-time. oracle/graal#6356 (needed so we can get org.graalvm.vendorversion to show up in native-image --version and in the build output).

[zakkak]

That should be good enough. Thoughts?

I agree with the above two patches, but I think the bash-launcher should print the "Substrate VM" in the 3rd line as well.

Furthermore, I am still not sold on Mandrel-23.0.0-dev, not sure we want to keep using YY.X.Z versioning once GraalVM CE abandons it.

To be inline with upstream GraalVM CE releases I would expect something like the following:

$ native-image --version
native-image 17.0.6.2-dev 2023-01-17
GraalVM Runtime Environment Mandrel Distribution (build 17.0.6+10)
Substrate VM Mandrel Distribution (build 17.0.6+10, serial gc)

Notice that the .2 part in the first line indicates the Mandrel/GraalVM post-release version (i.e. patches applied after the last release but before the next CPU update)

[jerboaa]

17.0.6.2-dev

Note that the value comes from System.getProperty("java.version") which we cannot modify. It comes from OpenJDK and we don't jlink. See https://github.com/oracle/graal/pull/6302/files#diff-25ec60a6e76682aa4e4a21d2743519143e053be221fe53d584d8b074ec8ae7caR197

So I'm not sure we can modify it. That version also changes whether or not this is a JDK 17 based build or a, say, JDK 20 based build (for the same Mandrel code level). To me the vendor version seems most flexible and the right thing to use (over any of the other non-vendor-JDK properties).

[zakkak]

We could ask upstream to reintroduce org.graalvm.version (which can default to java.version) for this.

What I am trying to avoid is looking at different places to figure out the version depending on whether you are using GraalVM CE, Mandrel or another distribution.

[jerboaa]

We could ask upstream to reintroduce org.graalvm.version (which can default to java.version) for this.

Possibly. With my OpenJDK hat on, I don't like it as it looks as if it was an OpenJDK version, which it isn't.

What I am trying to avoid is looking at different places to figure out the version depending on whether you are using GraalVM CE, Mandrel or another distribution.

Makes sense, and it would be ideal yes.

[jerboaa]

To be inline with upstream GraalVM CE releases I would expect something like the following:

$ native-image --version
native-image 17.0.6.2-dev 2023-01-17
GraalVM Runtime Environment Mandrel Distribution (build 17.0.6+10)
Substrate VM Mandrel Distribution (build 17.0.6+10, serial gc)

For the bash launcher, using GraalVM Runtime Environment doesn't make sense. native-image is just a fancy java program. Same for the VM. If running on Hotspot (for the bash launcher), it doesn't seem correct. For an AOT compiled, native-image it would look like the above yes. See: #491 (comment)

I guess it isn't hugely important, as long as we can reach consensus.

[jerboaa]

Quarkus update: quarkusio/quarkus#32366

[jerboaa]

For the time being it'll look like as proposed in: #491 (comment)

The vendor version might change in the future, but that's for another day.