OpenJDK Updates Project Builds

Fri Apr 26 23:18:06 UTC 2019

> On Apr 26, 2019, at 10:18 AM, Andrew John Hughes <gnu.andrew at redhat.com> wrote:
> 
> 
> 
> 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?

I'm in no way saying that "8u40" identifies a specific build or a specific
set of code.

What I am saying is that before 8u40 was actually released (in the
project, with a known  set of code for it's "ga"), nothing else can
be called 8u40 (without a clear "this is not the final 8u40" thing in the
version string) without sowing lasting confusion.

IMO anything reporting as e.g. "8u40" after the GA is purporting to be
"based on" the actual GA'ed 8u40. It can include significant changes
(as do some downstream variants) and still call itself 8u40 IMO.

However, "I'll replace half the code but still have an identical version
string output" is probably bad practice. When a build significantly differs
in functionality from what a vanilla build of the same GA'ed version name
in the OpenJDK 8u project sources would be, it should probably clearly
identify itself as something else in the version string as well. Most of us
seem to do that clearly with things like "IcedTea", "Zulu", "Corretto",
"AdoptOpenJDK", etc. sowing up in e.g. the second line of the version
string.

> With those early
> releases, it's not even obvious from the repositories which is "ga".

It's pretty clear what "GA" for 8u40 was:
https://wiki.openjdk.java.net/display/jdk8u/JDK+8u40

And this was not that early. This was a year into 8u. Well beyond
where e.g. 11u is right now.

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

I'd bet tens of millions of installations were running various OpenJDK 8u
builds by the date that this "fake 8u40" was no longer the thing that "docker
run java" was giving you.

And because of the unfortunate seepage of this specific example into
docker's "blessed" images for java:8 for a period of 6 months, millions of
instances were likely running something that was quite different from what
they thought it was. Real releases were being made (e.g. both 8u25 and 8u31
happened during this timeframe), but docker java:8 users would have seen
this "fake 8u40" instead without knowing it.

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

I would hope that when AArch32 and AArch64 builds calling themselves
8u40 (or any other version) without some clear EA marking, they would
be based on the source code in 8u40, and not on some snapshot of that
code's evolution 5 months before GA.

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

We agree that there is no "same exact set of sources" meaning here. And
I suspect that we also agreed that it should be "based on the actually
released set of sources".

> The end user needs to be aware of where they are
> obtaining their builds from and what that entails.

That's a pretty impossible thing to ask the "end user" of an installed
JDK or a docker image. Such users can only practically verify the
thing they are running by asking it what it is (with e.g. -version).

If such users know that they got their stuff "from a reputable source"
(e.g. they rememeber that they only downloaded their JDKs from
https://adoptopenjdk.net/upstream.html, or from the docker hub's
blessed "java" image), they will tend to trust that the -version update
means what it says, even when they run the java -version
command months after they installed the JDK. This is why reputable
sources should never provide early access builds with version output
that does not clearly identify them as such.

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