Add metadata version to java.vendor.version

[andrew-m-leonard]

Update jdk11+ java.vendor.version for Adopt binaries to be:
AdoptOpenJDK-<metadata version>

Signed-off-by: Andrew Leonard [email protected]

[andrew-m-leonard]

Dragonwell example:

--with-vendor-version-string="(Alibaba Dragonwell)"-11.0.10+0-202103241119

Adopt nightly:

    java.vendor.version = AdoptOpenJDK-11.0.11+7-202103230931
openjdk version "11.0.11" 2021-04-20
OpenJDK Runtime Environment AdoptOpenJDK-11.0.11+7-202103230931 (build 11.0.11+7-202103230931)
OpenJDK 64-Bit Server VM AdoptOpenJDK-11.0.11+7-202103230931 (build 11.0.11+7-202103230931, mixed mode)

Adopt release:

    java.vendor.version = AdoptOpenJDK-16+36
openjdk version "16" 2021-03-16
OpenJDK Runtime Environment AdoptOpenJDK-16+36 (build 16+36)
OpenJDK 64-Bit Server VM AdoptOpenJDK-16+36 (build 16+36, mixed mode, sharing)

[M-Davies]

Checked out the artifacts and the code, looks good! 👍

[aahlenst]

On Slack, Andrew raised the question whether it's okay that we now have

OpenJDK Runtime Environment AdoptOpenJDK-16+36 (build 16+36)

instead of

OpenJDK Runtime Environment AdoptOpenJDK (build 16+36)

I think it makes sense and that's what we're supposed to do. Because what's in the brackets is OpenJDK's version and we should add our own which by accident (Narrator: It's not.) is the same as OpenJDK's.

That's how it looks in the case of Azul Zulu:

OpenJDK Runtime Environment Zulu16.28+11-CA (build 16+36)

Let's also have a look at the last time we did a .1: https://github.com/AdoptOpenJDK/openjdk11-binaries/releases/tag/jdk-11.0.9%2B11.1. That's what comes out of it:

OpenJDK Runtime Environment AdoptOpenJDK (build 11.0.9+11)

How on earth should anybody know whether that's the .1 or not?

@andrew-m-leonard Would a .1 appear in java.vendor.version?

[sxa]

I don't believe we've ever put the buildNumber (the .1 in your question) anywhere in the binary itself - only the tarball. I would also suggest that unless we change policy and want to put it in there, then the duplication of 16.36` in here seems superficially pointless (To be clear: this comment isn't me saying it should be removed, but as Andreas said if we're making a change to expose it we ought to call out that we're doing tit)

OpenJDK Runtime Environment AdoptOpenJDK-16+36 (build 16+36)

Presumably this is currently matching what the smoke tests are coded to expect?

[andrew-m-leonard]

I don't believe we've ever put the buildNumber (the .1 in your question) anywhere in the binary itself - only the tarball. I would also suggest that unless we change policy and want to put it in there, then the duplication of 16.36` in here seems superficially pointless (To be clear: this comment isn't me saying it should be removed, but as Andreas said if we're making a change to expose it we ought to call out that we're doing tit)

OpenJDK Runtime Environment AdoptOpenJDK-16+36 (build 16+36)

Presumably this is currently matching what the smoke tests are coded to expect?

@sxa I don't believe the SmokeTest code to check this has been written yet... it's waiting for me to merge this so they know what to check....

[andrew-m-leonard]

@aahlenst so as @sxa mentioned the .1 is just added to the metadata during tarball creation.
Interesting for Zulu example: OpenJDK Runtime Environment Zulu16.28+11-CA (build 16+36)
The Zulu version is not the same as the build version 16.28+11 != 16+36, so sort of makes sense.
We're not really adding anything with AdoptOpenJDK-16+36 (build 16+36) ?

However we are setting the "java.vendor.version" sys property...

The assumption in the generation of the java -version output is that vendor version is different to the runtime version:
https://github.com/openjdk/jdk/blob/c037e1edaf7f628b3e6a0b57a1029e0cdd134dc8/src/java.base/share/classes/java/lang/VersionProps.java.template#L230

ps.println(java_runtime_name + vendor_version
                   + " (" + jdk_debug_level + "build " + java_runtime_version + ")");

[aahlenst]

I don't believe the SmokeTest code to check this has been written yet...

It was. That's how we found the problem (if it's one). The test can be changed. However, reading:

ps.println(java_runtime_name + vendor_version
                   + " (" + jdk_debug_level + "build " + java_runtime_version + ")");

If we don't want to have a vendor version, why not leave it empty, then, and change java.runtime.name? Using the version property without willing to specify a version seems nonsensical to me.

[andrew-m-leonard]

@aahlenst ah, I couldn't find any test? could you point me at it please? would help me solve the problem

[sxa]

@andrew-m-leonard I'm guessing he's referring to the stuff at https://github.com/AdoptOpenJDK/openjdk-build/tree/master/test/functional/buildAndPackage

[aahlenst]

https://github.com/AdoptOpenJDK/openjdk-build/blob/d04092129b1e35d2c8aab3aaa83d565905aa38f3/test/functional/buildAndPackage/src/net/adoptopenjdk/test/VendorPropertiesTest.java#L84

[karianna]

LGTM