OpenJDK Updates Project Builds

Fri Apr 26 16:29:16 UTC 2019

I tend to agree with Gil here, it's a matter of consistency to have EA
builds advertise as EA builds in the most clear way possible, as well
as a courtesy.

Cheers,
Mario

On Fri, Apr 26, 2019 at 6:23 PM Gil Tene <gil at azul.com> wrote:
>
>
>
> > On Apr 26, 2019, at 7:47 AM, Gil Tene <gil at azul.com> wrote:
> >
> >
> >
> > 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.
>
> for specific reference:
>
> If I go to https://adoptopenjdk.net/upstream.html
>
> And follow the link labeld "Linux x86_64 8u212-b02-ea" to https://github.com/AdoptOpenJDK/openjdk8-upstream-binaries/releases/download/jdk8u212-b02/OpenJDK8U-x64_linux_8u212b02_ea.tar.gz
>
> And untar it
>
> It untar to a directory called openjdk-8u212-b02.
>
> If I then come back three months later looking for 8u212, I'll find this nice openjdk-8u212-b02 thing there, and if I run it I would see:
>
> gil at ubuntu:~/work/openjdk-8u212-b02$ bin/java -version
> openjdk version "1.8.0_212"
> OpenJDK Runtime Environment (build 1.8.0_212-b02)
> OpenJDK 64-Bit Server VM (build 25.212-b02, mixed mode)
>
> If I were super diligent about checking all build bumbers against konw build numbers of actual releases, I might notice that b02 was never released. But the likelihood of noticing that is very low…
>
> A "better named" directory might help a bit, but the only real place to label things is in the -version output. That's the thing all of us look at when we want to find our what a build actually is.
>
> >
> >
> > 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
>

-- 
Mario Torre
Associate Manager, Software Engineering
Red Hat GmbH <https://www.redhat.com>
9704 A60C B4BE A8B8 0F30  9205 5D7E 4952 3F65 7898