Temurin-build: Change version block to highlight update, build number and community information

[karianna]

There's a challenge involved in making version numbers give credit to the produce for Java. The following issue discusses this: https://bugs.openjdk.java.net/browse/JDK-8189761 and a fix was applied for Java 10 and 11 which seems to also be back ported to 9. However, this is not backported to Java 8, so we have some back porting work to do

---

Our existing 8 builds produce a Java 8 version like this:

openjdk version "1.8.0_181"
OpenJDK Runtime Environment (AdoptOpenJDK) (build 1.8.0_181-13)
OpenJDK 64-Bit Server VM (build 25.181-b13, mixed mode)

However, this is done using a hack which also overrides the java.runtime.name property, which we don't want to do as there is tooling in the wild that relies on it.

---

Now onto what Oracle produces and what we want to produce. Oracle currently produces this:

_Java 8:_

java version "1.8.0_181"
Java(TM) SE Runtime Environment (build 1.8.0_181-b13)
Java HotSpot(TM) 64-Bit Server VM (build 25.181-b13, mixed mode)

_Java 9:_

java version "9.0.4"
Java(TM) SE Runtime Environment (build 9.0.4+11)
Java HotSpot(TM) 64-Bit Server VM (build 9.0.4+11, mixed mode)

_Java 10:_

Interesting how they add the date here

java version "10.0.2" 2018-07-17
Java(TM) SE Runtime Environment 18.3 (build 10.0.2+13)
Java HotSpot(TM) 64-Bit Server VM 18.3 (build 10.0.2+13, mixed mode)

---

For releases I think AdoptOpenJDK should produce something similar to:

_Java 8_

openjdk version "1.8.0_181"
OpenJDK Runtime Environment (build 1.8.0_181-b13-adoptopendk)
OpenJDK 64-Bit Server VM (build 25.181-b13, mixed mode)

_Java 9_

Note patch number is specified in JEP 223 but is rarely used.

java version "9.0.4.<patch number>"
OpenJDK Runtime Environment (build 9.0.4+11-adoptopenjdk)
Java HotSpot(TM) 64-Bit Server VM (build 9.0.4+11, mixed mode)

_Java 10_

Note date format matches Oracle's JDK. Note patch number is specified in JEP 223 but is rarely used.

java version "10.0.2.<patch number>" 2018-07-17
OpenJDK Runtime Environment 18.3 (build 10.0.2+13-adoptopenjdk)
OpenJDK 64-Bit Server VM 18.3 (build 10.0.2+13, mixed mode)

---

For nightlies I think AdoptOpenJDK should produce something similar to:

_Java 8_

openjdk version "1.8.0_181"
OpenJDK Runtime Environment (build 1.8.0_181-b13-adoptopendk-yyyymmdd)
OpenJDK 64-Bit Server VM (build 25.181-b13, mixed mode)

_Java 9_

java version "9.0.4.<patch number>"
OpenJDK Runtime Environment (build 9.0.4+11-adoptopenjdk-yyyymmdd)
Java HotSpot(TM) 64-Bit Server VM (build 9.0.4+11, mixed mode)

_Java 10_

Note date format matches Oracle's JDK. Note patch number is specified in JEP 223 but is rarely used.

java version "10.0.2.<patch number>" yyyy-mm-dd
OpenJDK Runtime Environment 18.3 (build 10.0.2+13-adoptopenjdk-yyyymmdd)
OpenJDK 64-Bit Server VM 18.3 (build 10.0.2+13, mixed mode)

---

In conclusion we'll attempt to match Oracle's naming conventions as closely as possible to avoid breaking tooling in the wild. We'll use configure properties for 9+ to create the version string we want and attempt to back port a patch to Java 8 to allow us to do the same thing.

[Joe-Brady]

Sounds good!

[tellison]

This is achieved during the ./configure stage. Here are the options you can use, with their [default values]

  --with-milestone        Set milestone value for build [internal]
  --with-update-version   Set update version value for build [b00]
  --with-user-release-suffix
                          Add a custom string to the version string if build
                          number isn't set.[username_builddateb00]
  --with-build-number     Set build number value for build [b00]
  --with-copyright-year   Set copyright year value for build [current year]

[karianna]

End result is:

openjdk version "1.8.0_131-adoptopenjdk"
OpenJDK Runtime Environment (build 1.8.0_131-adoptopenjdk-jenkins_2017_04_17_17_21-b00)
OpenJDK 64-Bit Server VM (build 25.71-b00, mixed mode)

[karianna]

Still an open question on what we want to do with the build number (it's defaulting to b00). Do we match the build number of the tag we pull from the mercurial forest or apply our own?

[karianna]

I've gone with the correspnoding build number from the OpenJDK forest for now.

Have also asked the Q on the version update number http://mail.openjdk.java.net/pipermail/jdk8u-dev/2017-May/006649.html

[karianna]

Hmm latest builds are still reporting:

openjdk version "1.8.0-internal"
OpenJDK Runtime Environment (build 1.8.0-internal-jenkins_2017_05_31_17_02-b00)
OpenJDK 64-Bit Server VM (build 25.71-b00, mixed mode)

[bpasson]

Any update on when the java -version output is going to be updated? Latest builds are still reporting:

openjdk version "1.8.0-internal"
OpenJDK Runtime Environment (build 1.8.0-internal-jenkins_2017_07_27_20_16-b00)
OpenJDK 64-Bit Server VM (build 25.71-b00, mixed mode)

[karianna]

@neomatrix369 I think we might need to pair on this and get it resolved. I'll arrange a time on slack

[neomatrix369]

@karianna This might be lightly related to issue https://github.com/AdoptOpenJDK/openjdk-build/issues/98

[neomatrix369]

@karianna Happy to take a look at this issue, lets discuss this next time on slack

[neomatrix369]

Please also look at related discussions on https://github.com/AdoptOpenJDK/openjdk-build/issues/204#issuecomment-358839983

[karianna]

@gdams recently put in #256 - time to look at this again.

[karianna]

Got a private email with:

AdoptOpenJDK builds report versions with a zero for the build number, like:

$ jdk-9+181/bin/java -version
openjdk version "9-internal"
OpenJDK Runtime Environment (build 9-internal+0-adhoc..openjdk)
OpenJDK 64-Bit Server VM (build 9-internal+0-adhoc..openjdk, mixed mode)

OP had a peek at the build scripts and see there's logic for finding the last tag ("OpenJDK repo tag is jdk-9+181").

[karianna]

Also we should replace adhoc with adoptopenjdk

[gdams]

hmmm the version should be working...

I was able to get Version string: 9-adoptopenjdk+181 (9-adoptopenjdk) when testing locally

[karianna]

Downloading latest 9 for Hotspot from site I get:

openjdk 9-internal
OpenJDK Runtime Environment (build 9-internal+0-adhoc.jenkins.openjdk)
OpenJDK 64-Bit Server VM (build 9-internal+0-adhoc.jenkins.openjdk, mixed mode)

[neomatrix369]

While building Graal/GraalVM the feedback from others was that the JDK (JDK 8 via Adopt docker image) used did not print a build number in the version string :

openjdk version "1.8.0-internal"
OpenJDK Runtime Environment (build 1.8.0-internal-jenkins_2017_07_27_20_16-b00)
OpenJDK 64-Bit Server VM (build 25.71-b00, mixed mode)

The name of the folder in which the JDK is present is jdk8u144-b01.

Ideally, the below would be helpful:

java version "1.8.0_144"
Java(TM) SE Runtime Environment (build 1.8.0_144-b01-adoptopenjdk)
Java HotSpot(TM) 64-Bit Server VM (build 25.144-b01-adoptopenjdk, mixed mode)

We must have this information to hand, i'm guessing otherwise we couldn't name the folder.

[neomatrix369]

Is someone looking at something like this? https://github.com/AdoptOpenJDK/openjdk-build/issues/93#issuecomment-399652750 I can have a quick look at the scripts to see how this is done, but will stay away if someone is already onto it or it will be resolved via another process.

[karianna]

Will pick this up as part of the build script overhaul this week.

[SueChaplain]

Interesting that the Oracle java -version for Java 9 doesn't seem to apply JEP223 completely, although perhaps they left off $PATCH as this is currently "0". Guess the plan needs to cater for the possibility of a $PATCH number.

Java 9:

java version "9.0.4"

$MAJOR.$MINOR.$SECURITY.$PATCH

[sxa]

We should also document the impact to the other builds in this issue - OpenJ9, amber etc.

[karianna]

For folks following this, I've edited and updated the original problem description to match what we understand today.

[karianna]

@SueChaplain Thank you for that timely reminder!

[karianna]

See #465 to continue this exciting saga.