OpenJDK Updates Project Builds

[Gil Tene]

Sent from my iPad

On Apr 26, 2019, at 5:28 AM, Severin Gehwolf <sgehwolf at redhat.com<mailto:sgehwolf at redhat.com>> wrote:

On Fri, 2019-04-26 at 14:11 +0200, Dalibor Topic wrote:
Hi,

the Early Access (EA) builds on https://adoptopenjdk.net/upstream.html
are still confusingly versioned on that site, unfortunately. To quote
from [0]:

"E.g. what tells an end user that +7 and +31 are release builds, but +6
and +11 are not?"

I'm not 100% clear what you mean. To answer the question: The filename?
"java -version" output?

$ ls -1
OpenJDK11U-x64_linux_11.0.3_6_ea.tar.gz
OpenJDK11U-x64_linux_11.0.3_7.tar.gz

$ ./openjdk-11.0.3+6/bin/java -version
openjdk version "11.0.3-ea" 2019-04-16
OpenJDK Runtime Environment 18.9 (build 11.0.3-ea+6)
OpenJDK 64-Bit Server VM 18.9 (build 11.0.3-ea+6, mixed mode)

$ ./openjdk-11.0.3+7/bin/java -version
openjdk version "11.0.3" 2019-04-16
OpenJDK Runtime Environment 18.9 (build 11.0.3+7)
OpenJDK 64-Bit Server VM 18.9 (build 11.0.3+7, mixed mode)

For JDK 8u it won't show up in the version output, but I'm not sure
that can be helped. Archive file names still have "ea" in their name
and the build numbers show up in version output so as to distinguish
them.

I would highly recommend/request/beg/plead that the -version string of any posed EA builds be modified to clearly identify as EA (like the 11 builds do above). And that all current builds that don’t do that be taken down ASAP to prevent damage.

This (EA builds of 8u that show -version numbers that look very much like releases but are not) is a very serious problem. The file name, the web link, and the text in the web page don’t survive installation. And what you have left around then is a “mystery meat” JDK that made it into the wild. These things can (and do) then end up in places and situations where vast numbers of people end up using unreleased builds, often in production, without knowing it.

For a concrete historical example of how bad something like this can (and did) get when you don’t take care to identify EA’ness in the actual version string output: Between Sep. 2014 and March 2015 (I.e. for the ~6 month period before 8u40 was actually released) running “docker run java:8 -version” reported the version as 8u40, with nothing to indicate the JDK you were running was experimental or EA. This was a result of an unfortunate choice to take the blessed docker java image’s JDK from a Debian unstable release, which was building an unreleased OpenJDK (with the Debian folks probably thinking “this Debian distro and repo are clearly unstable/experimental, so people would know not to take bits from it to production”). This JDK then ended up in the “blessed” docker image for java, with nothing to identify it as a non-released JDK. And as a result everyone that read articles like https://blog.giantswarm.io/getting-started-with-java-development-on-docker/ ended up using an 8u40 that wasn’t 8u40 without knowing it, and with no obvious way to tell, even after the real 8 u40 was released. It is likely that millions of people were affected by this.

Bottom line: Please please please don’t put up binary builds of non-released JDKs that do not clearly identify them as such in the version actual string output. And if you did, please tear them down ASAP to limit potential damage.


Thanks,
Severin



cheers,
dalibor topic

[0]
https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2019-April/000962.html

On 16.04.2019 21:49, Dalibor Topic wrote:
On 15.04.2019 12:25, Andrew Haley wrote:
we now have early access
preview Linux and Windows binaries (currently x86-64 only) at

https://adoptopenjdk.net/upstream.html

I would suggest using the version nomenclature per JEP 322, i.e.

"A version string is a version number, $VNUM, possibly followed by
pre-release, build, and other optional information, one of:

$VNUM(-$PRE)?\+$BUILD(-$OPT)?
$VNUM-$PRE(-$OPT)?
$VNUM(+-$OPT)?

where $PRE is a pre-release identifier (e.g., ea), $BUILD is a
build
number, and $OPT is optional build information."

i.e. 11.0.3-ea+6, for example.

cheers,
dalibor topic