OpenJDK Updates Project Builds

[Andrew John Hughes]

On 26/04/2019 15:47, Gil Tene wrote:
> 
snip...

> 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
> 

I agree with making it clear that these builds are early access builds
in the version output. A brief look suggests that --with-milestone=ea
would be the way to do that, but I'm open to better suggestions from
those who are more familiar with that part of the 8u build.

Further to that, I was musing over the idea earlier in the week that we
should have better defaults for versioning in 8u. At present,
downstreams have to add the update & build numbers, with the default
being along the lines of:

$ /mnt/builder/8u-dev/images/j2sdk-image/bin/java -version
openjdk version "1.8.0-internal"
OpenJDK Runtime Environment (build
1.8.0-internal-andre_2019_04_25_05_13-b00)
OpenJDK 64-Bit Server VM (build 25.71-b00, mixed mode)

Unlike 11, the version numbers are not included in
common/autoconf/version-numbers, but instead have to be set by
downstreams. I feel, if we have better defaults there, there would be
less cause for downstream builds to set these values and cause
divergence. That would mean updating these values in OpenJDK as part of
the tagging process, and explicitly removing and re-adding "ea" either
side of "ga".

However, I do take issue with this idea of a "real 8u40". What would
that be? Is it the vanilla OpenJDK sources as tagged? With those early
releases, it's not even obvious from the repositories which is "ga". If
that is the "real 8u40", then few people are using it, because Oracle's
8u40 diverges from upstream, as do most other downstreams packaged in
various distributions and the like. For instance, anyone using 8u with
the AArch32 or AArch64 ports does not have the "real" 8u because those
ports are added downstream in the appropriate projects.

So, while I agree that we should make clear which builds produced by the
OpenJDK projects are intended for production use and which aren't, the
idea that a particular update designation such as "8u40" in a build
always refers to one built from the same exact set of sources is
fanciful at best. The end user needs to be aware of where they are
obtaining their builds from and what that entails.

Thanks,
-- 
Andrew :)

Senior Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net)
Fingerprint = 5132 579D D154 0ED2 3E04  C5A0 CFDA 0F9B 3596 4222
https://keybase.io/gnu_andrew