Use OpenJDK builds provided by jdk.java.net?

[agudian]

With Oracle providing builds of OpenJDK (including updates) on http://jdk.java.net under the GPLv2 (with Classpath Exception), how about using those binaries the Docker images?

That would allow more timely updates and decouple the Java version updates from package and version cycles of the different Linux distros. That would be interesting especially for the Alpine variants that missed most of the last updates.

Or does anything speak against that?

(this is a bit more general than what's asked in #211)

[tianon]

IMO that's a really interesting idea, although our number of supported architectures would drop to almost nothing right away 😕

[agudian]

Of course it only makes sense on architectures that are supported by the builds, and keep using provided packages of the individual distributions otherwise.

And it looks like at least an additional Apline binary is already provided for the JDK 11 ea version, which is a good sign.

[tianon]

That's definitely a no-go unless the provided packages match what the distributions provide reasonably closely (and I don't believe that they do); we try to keep the images for multiple architectures as similar as possible to avoid unexpected issues due to architecture changes.

[panga]

This will prevent issues like #217

[tianon]

https://twitter.com/robilad/status/1032525402433101824?s=19 is a pretty compelling argument IMO, although losing so many arches still makes me a little sad -- what's the compelling story for those existing users? 😔

(ibmjava is probably a decent rec for IBM arches, but this would leave arm users out cold)

[tianon]

Also worth pointing out this wouldn't provide jdk 7 or 8, but maybe that's not really all that important. 😅

[tianon]

@Djelibeybi in thinking about this, I was considering adding Oracle Linux-based variants, and using those to provide the official upstream-provided JDK -- what are your thoughts around that? That would help us navigate the backwards compatibility concerns, and make it clear this is something separate from what's been published so far.

Currently, our tags include the Debian release name (stretch, jessie, alpine3.8, etc), so for this I'd imagine adding something like -oracle7, etc. (or would we have to go all the way to -oraclelinux7?)

[Djelibeybi]

Sorry @tianon, I meant to reply earlier but forgot. This week has been hectic.

We'd prefer oraclelinux7 but if making it shorter is required, please use ol7 instead.

[tianon]

It's not required per se, but oraclelinux7 is really a mouthful for users who want to use the upstream bits to have to type out explicitly. 😄

So do you think my approach of making Oracle Linux-based variants for hosting the official upstream builds makes sense to help us navigate the issues around switching to those officially? Is there a better solution we should be considering? 😅

[Djelibeybi]

It's not required per se, but oraclelinux7 is really a mouthful for users who want to use the upstream bits to have to type out explicitly

As a compromise, how about just using -oracle to indicate all the bits are Oracle bits?

Is there a better solution we should be considering?

I can't think of a better solution, so this one will have to do. 😂

[tianon]

Here's a PoC of what I've got for OpenJDK 10:

FROM oraclelinux:7-slim

RUN set -eux; \
	yum install -y \
		gzip \
		tar \
	; \
	rm -rf /var/cache/yum

ENV JAVA_HOME /opt/jdk
ENV PATH $JAVA_HOME/bin:$PATH

ENV JAVA_VERSION 10.0.2
ENV JAVA_URL https://download.java.net/java/GA/jdk10/10.0.2/19aef61b38124481863b1413dce1855f/13/openjdk-10.0.2_linux-x64_bin.tar.gz
ENV JAVA_SHA256 f3b26abc9990a0b8929781310e14a339a7542adfd6596afb842fa0dd7e3848b2

RUN set -eux; \
	curl -fL -o /openjdk.tgz "$JAVA_URL"; \
	echo "$JAVA_SHA256 */openjdk.tgz" | sha256sum -c -; \
	tar --extract --file /openjdk.tgz --directory /opt; \
	rm /openjdk.tgz; \
	ln -sfT "/opt/jdk-$JAVA_VERSION" "$JAVA_HOME"; \
	"$JAVA_HOME/bin/java" -version; \
	"$JAVA_HOME/bin/javac" -version

CMD ["jshell"]

Size comparisons:

• openjdk:10-jdk: ~976MB
• openjdk:10-jdk-slim: ~497MB
• new Dockerfile above: ~471MB ❗

I played with installing and removing tar and gzip in the RUN line, but the current layer above is ~10MB, and ~8MB of that is in /var/lib/rpm (where changes do not go away via yum remove, yum history undo, etc), so we'd only save ~2MB by doing so. 😆