Skip to content

Commit

Permalink
Update Java 8 to 8u40
Browse files Browse the repository at this point in the history
  • Loading branch information
@tianon
tianon committed Sep 13, 2014
1 parent 3c81719 commit 00a9c5c
Showing 1 changed file with 1 addition and 1 deletion.
2 changes: 1 addition & 1 deletion 8/Dockerfile
View file
Original file line number Diff line number Diff line change
Expand Up @@ -5,7 +5,7 @@ FROM debian:experimental
# 2. Compiling OpenJDK also requires the JDK to be installed, and it gets
# really hairy.

ENV JAVA_VERSION 8u20
ENV JAVA_VERSION 8u40

RUN apt-get update && apt-get install -y curl openjdk-8-jdk="$JAVA_VERSION"* unzip wget

Expand Down

7 comments on commit 00a9c5c

@giltene
Copy link

@giltene giltene commented on 00a9c5c Oct 3, 2014

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Um... I think this 8u40 version is a bit of a problem, especially for an official docker runtime image.

The problem is that 8u40 does not [yet] exist. It is not scheduled to be release until March 2015 (see http://openjdk.java.net/projects/jdk8u/releases/8u40.html). So whatever these bits are they are not an actual 8u40 thing, and not a tested or stable OpenJDK 8 build. [It looks like the previous 8u20 version this replaced was also built before 8u20 was actually released, so it's bit are likely not really 8u20 either.]

I'd recommend that you use tested, compatibility verified OpenJDK builds for your official language runtime images. There are several companies that actually license the OpenJDK TCK from Oracle, test their builds of OpenJDK, and make them freely available in redistributable. You can find the list of companies and organization that are able to test their OpenJDK builds against the TCK at http://openjdk.java.net/groups/conformance/JckAccess/jck-access.html .

Azul Systems (where I am proud to be CTO) is one of those. And AFAIK we are currently the only ones making TCK-tested OpenJDK 8 binaries for debian and ubuntu distros available (and so far also for RHEL and centos for that matter). We also diligently build up to date OpenJDK 7 and 6 versions, and we make all our builds freely available (and freely redistributable) for Linux, Mac, and Windows platforms.

So if you are looking for a tested & verified binary build of OpenJDK 8 (or 7 or 6) to use and point to, you can use Azul's Zulu distribution. We have images of all our latest Zulu builds up at https://registry.hub.docker.com/u/azul/zulu-openjdk-debian/ . E.g. the dockerfile for a TCK-tested binary build of OpenJDK 8u20 is at https://github.com/zulu-openjdk/zulu-openjdk/blob/master/debian/8u20-8.3.0.1/Dockerfile . You can find our certificate indicating that that the specific binary on our repo and web site has been verified against TCK and is Java SE 8 compatible at http://www.azulsystems.com/sites/default/files//pdf/cert.zulu1.8.0_20-8.3.0.1_amd64.deb.pdf

Please feel free to contact me on twitter @giltene (where I already follow you)...

@yosifkit
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We are following the most recent version specified in the debian sid repositories. Since this is sid, it is the "unstable distribution". The packages will change over time until the "GA" release but as the openjdk pages indicate 8u40 is "Feature Complete", which is why it is in debian unstable.

Would having both 8u40 and 8u20 be more useful to users?

Unfortunately, I don't think we should take any "compatible" variants of the openjdk from other companies and call it openJDK. The JCK/TCK only requires a "compatible Java implementation based on code derived from OpenJDK".

If Azul Systems wants to contribute, we are open to adding zulu images into the Docker "Official Images". These zulu images could be java:zulu, java:zulu-8, and java:zulu-8-jdk. See docs.docker for more information about contributing on Official Images. If you have any questions, feel free to ping @tianon or myself here or on freenode IRC.

@tianon
Copy link
Member Author

@tianon tianon commented on 00a9c5c Oct 3, 2014 via email

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@giltene
Copy link

@giltene giltene commented on 00a9c5c Oct 3, 2014

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@yosifkit: We'll be happy to contribute as you noted. However, I think you misunderstand the meaning of the words compatible and compliant when it comes to JDKs. The word compatible carries a heavy meaning (as in COMPATIBLE, rather than "compatible"). Things that did not pass the TCK/JCK tests cannot claim compatibility or compliance with the Java SE specifications. Only things (actual binaries) that had actually had the tests performed can make that claim. AFAIK, the 8u40 bits you are currently using are not that [unless you know of someone who has actually performed the proper tests on them, which I doubt both based on the pre-release contents, and based on the list of OpenJDK TCK signatories].

When you worry about taking binaries from "other companies" and calling them openjdk, it's worth noting that the OpenJDK project does not provide binaries, only sources. So whatever binaries you end up taking will be coming from "other companies". They do not come from Oracle or the OpenJDK project itself. These binaries will either closely follow the released OpenJDK contents and be diligently tested (as Zulu does), or they won't. "Zulu is a binary build of OpenJDK" will be a fair statement. So will "Zulu 8 is a binary build of OpenJDK 8 that has been tested against the Java SE 8 TCK, and certified as compatible with the Java SE spec". I'm pretty sure the same can't be said about the experimental 8u40 binary build that you currently carry under the label "openjdk".

So Zulu is much more than a "compatible" thing, or a "variant" of OpenJDK. Currently, Zulu is the [currently] only OpenJDK 8 binary build available for use out there that has actually been built and fully tested. Zulu does not vary from OpenJDK. Instead, it is a COMPATIBLE and COMPLIANT binary build of OpenJDK 8, 7, and 6. And Azul certifies that the specific Zulu binary you get your hands on was actually tested, rather than just the sources it came from.

So Zulu provides a trusted, certified build of OpenJDK to the community as a whole. It diligently sticks to the actual released OpenJDK sources, updating upstream with bug fixes as needed, and each Zulu binary build is separately tested against the full TCK suite (as well as a lot of other internal tests) to verify that the binary (and not just the sources it came from) fully passes.

Since the vast majority of the Java developer community is already using Java 8 on their IDEs, and many are moving to production with 8u20, making the official, trusted language runtime on docker based on an untested experimental build that is still a moving target (and is not being tested fully) does not make much sense in a Java deployment world. The proper versions of JDK you should have for you language runtimes at this point at 8u20 and 7u65. you can get obviously get good, tested versions of those JDKs from Oracle, and you can get freely redistributable versions of OpenJDK builds with Zulu for the same versions. Right now anything else is probably a bad version to seed an official language runtime image with.

@giltene
Copy link

@giltene giltene commented on 00a9c5c Oct 3, 2014

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@tianon: The fact the "install" link on the OpenJDK page does not list JDK 8 is not a "recommendation" against using it. JDK 8 and OpenJDK 8 were both GA'ed in March 2014, and has since been updated 3 times (8u5, 8u11, 8u20) on a predictable and planned schedule.. The OpenJDK project does not provide binaries. Only sources. Others (companies, organizations) build tested binaries of the JDKs and make them available. The stale "install" page reflects the fact that the main yum and apt-get repos have not been populated with tested builds on OpenJDK 8 yet. Why others haven't bothered to provide tested builds of the GA versions yet is something I cannot comment on, but Azul has been providing GA'ed OpenJDK 8 builds in step with Oracle's JDK 8 versions since the very start.

@ebourg
Copy link

@ebourg ebourg commented on 00a9c5c Mar 14, 2016

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

FWIW Canonical and Debian developers have access to the TCK for Java SE 8 and OpenJDK is used to rebuild and test ~1200 open source projects packaged in Debian/Ubuntu about once a week. So claiming that the OpenJDK packages are untested is more FUD than fact.

@giltene
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@ebourg: Facts are facts. Check the dates on the specifics logged in this discussion. Unfortunately, no amount of "folks have good intentions, and test against 1000s of oss projects, so what they put out must be good" has helped here.

To be clear: I'm very glad to see that both Canonical and Debian teams NOW have access to OpenJDK TCKs. I applaud you for being one of the people who has personally joined the OpenJDK TCK signatories list to make Debian testing possible. And I wholeheartedly hope that the TCKs are actually being used to test and verify the compatibility and spec compliance of the actual binary artifacts being put in repositories (as opposed to checking something built from the same sources). As a member of both the JCP and OpenJDK community, I would very much like to see all builds of Java and OpenJDK (that are not clearly labeled as prototype/EA) be produced in a responsible fashion. And in the Java world "responsible" equates to "the actual binary artifacts have passed the relevant Java SE version's TCKs".

But it's clear that at the times noted in this discussion that was not the case. The bits that were being shared and used by folks were of "clearly bad" origin and pedigree, simply based of the dates. And the TCKs were clearly not being run on them. It's hardly "FUD" to point out the specifics here: that bits in deb packages labeled openjdk-8 (at least as early as Sep. 14, 2014, and at least until March 2015) and the "official java" dockerfiles and images that were based on them were built from something that was not stable or released by OpenJDK, and was clearly not meant to be released. These deb packages were not named, marked or labeled as "experimental", "prototype", "early access", or any equivalent label. The version string you got when running them (with "java -version") identified the JDK as 8u40 (again, with no tags to warn folks). The only user-identifiable difference between these and the eventual (March 2015) actual release of OpenJDK 8u40 would be the reported build number. People mistakenly went to production with these bits thinking that they are "good" openjdk 8 bits. And for all we know, there may be folks sill running those bits, thinking they actually are OpenJDK 8u40.

And to avoid any of that "OpenJDK wasn't actually out yet" nonsense: OpenJDK was out, and people were using it in production well before the dates in this discussion. That's exactly why these bits were so problematic, since end users (and re-packagers like Docker) had no idea that they are somehow distinguished from "good" OpenJDK 8 bits that were production-worthy. OpenJDK 8 was GA'ed in March 2014. At the time this github discussion was created, it had already been updated with 8u5, 8u11, 8u20, and later with 8u25, all of which were stable GA versions. Those are the versions of OpenJDK 8 that would/should have been provided to someone pulling "openjdk-8" package (or getting hold of the deb package somehow) at any time prior to March 2015.

Unfortunately, this documented history of what some have now come to call "Mystery Meat" OpenJDK builds has cast a shadow on OpenJDK builds in general, and on Debian repositories specifically. That's bad for the OpenJDK community as a whole. I think that it would be good to offset and differentiate from the previous practice by providing specific documentation of TCK execution for each JDK or JRE binary artifact (when, what binary [with checksum] were they run on, etc.), and by making sure that things built from non-released source trees are clearly labeled in the package names and versions string (e.g. openjdk-9-ea would be a fine package to share with folks at this point, but please please please don't call it openjdk-9).

Here's hoping for a better, cleaner, and more responsible future for OpenJDK builds.

Please sign in to comment.