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

[Djelibeybi]

Well, at least we're somewhat aligned with the openjdk:10-jdk-slim size. I'm assuming the space is being consumed by the later in which the OpenJDK tarball is unpacked?

[tianon]

Yeah, the unpacked tarball is ~343MB by itself (combined with the unpacked oraclelinux:7-slim at ~117MB plus the ~10MB for the tar+gzip layer). I think this is totally sane size-wise, although there's probably a bit that could be done.

I looked around to see if there were things like docs we could safely purge, but there's only really man pages and they're pretty tiny:

$ docker run -it --rm 7ca986177e6e bash
bash-4.2# cd "$JAVA_HOME"
bash-4.2# du -hs * | sort -h
4.0K	release
144K	conf
252K	include
556K	legal
596K	bin
1.7M	man
84M	jmods
242M	lib

[Djelibeybi]

Yeah, the oraclelinux:7-slim image is built with tsflags=nodocs, i.e. RPM/yum is configured to not install the docs at all by default.

[tianon]

Right, but I'm talking about the tarballs from jdk.java.net (http://jdk.java.net/10/) which we're pulling OpenJDK from, but they don't even really have any docs to speak of (we'd save maybe 2MB at most), so not really worth doing anything extra there. 😆

[Djelibeybi]

Ah, gotcha. Let's ping @aureliogrb and see if he can suggest anything that could be removed.

[tianon]

(I'm also not entirely sure about where I'm extracting the tarball -- is there a more standard place I should put those contents than just /opt/jdk-xxx? I don't want to overlap with anything installed by RPMs either. 😅)

[Djelibeybi]

If you use the Oracle Java 8 Dockerfile[1] as a reference, then it should be unpacked to /usr/java/openjdk-11 and then linked to /usr/bin using the alternatives tool.

[1] https://github.com/oracle/docker-images/blob/master/OracleJava/java-8/Dockerfile

[tianon]

That misses a lot of other fun binaries like jshell -- is that intentional? (that's why we add $JAVA_HOME/bin directly to $PATH)

[Djelibeybi]

It's almost certainly not intentional. I would hazard a guess that the original author of that Dockerfile was intending to create the same links that the RPM installer does, but got lazy after three. 😂

[tianon]

Here's some size comparisons for OpenJDK 11 (the previous Dockerfile was OpenJDK 10):

• openjdk:11-jdk: ~982MB
• openjdk:11-jdk-slim: ~502MB
• new build: ~438MB

[robilad]

On a side note, you may want to use class data sharing archive in the OpenJDK image, to improve startup time and memory sharing. While there is a JEP to make CDS part of the default build at http://openjdk.java.net/jeps/341 at some point in the future, -Xshare:dump still needs to be run on install in current releases.

See https://docs.oracle.com/javase/10/vm/class-data-sharing.htm#JSJVM-GUID-7EAA3411-8CF0-4D19-BD05-DF5E1780AA91 for a reference, and https://mjg123.github.io/2017/10/02/JVM-startup.html for a longer overview.

[tianon]

Interesting!

For the above-mentioned OpenJDK 11 image (previously ~438MB), adding java -Xshare:dump to the list of commands we run after extracting the JDK puts our image at ~456MB (still quite reasonable, especially compared to the Debian-slim-based ~502MB).

[tianon]

Making an Alpine image based on https://download.java.net/java/early_access/alpine/28/binaries/openjdk-11+28_linux-x64-musl_bin.tar.gz, I got ~332MB. 😎

Regarding locales -- Debian includes C and C.UTF-8 only, so we explicitly set LANG to C.UTF-8 to make sure file.encoding is UTF-8. In Oracle Linux, we have a lot more locales available (even in -slim), but not C.UTF-8; is there a suitable alternative we should use? (it appears to default to POSIX, which probably isn't great for Java 😄)

[tianon]

It seems to do the right thing (System.getProperty("file.encoding") returns "UTF-8") if I use en_US.UTF-8, but en_US seems like kind of an odd default just to get UTF-8 file encoding. 😞

[robilad]

Fwiw, there is a draft JEP to use UTF-8 as the default Charset at some point in the future http://openjdk.java.net/jeps/8187041 .

Meanwhile, if you need to preset specific options for JDK tools, you can use the JDK_JAVA_OPTIONS Launcher Environment Variable, as described in https://docs.oracle.com/javase/10/tools/java.htm#GUID-3B1CE181-CD30-4178-9602-230B800D4FAE__USINGTHEJDK_JAVA_OPTIONSLAUNCHERENV-F3C0E3BA

[tianon]

JDK_JAVA_OPTIONS is an excellent option, but isn't that something that users of the image are likely to also want to set? (thus overwriting our value)

Really wish I could 👍 on JEP 8187041 directly (that would make this particular issue go away automatically). 😄

[tianon]

WIPs are up in https://github.com/infosiftr/openjdk/tree/oracle (see especially master...infosiftr:oracle to view the changes/additions all at once), if anyone wants to take a look. 👍

(Also includes Alpine builds for 11 and 12. 🤘)

[tianon]

Looks like 11 went GA recently (:confetti_ball:), but dropped Alpine/musl builds entirely (:disappointed:). (http://jdk.java.net/11/)

[keckelt]

The early access alpine builds were also published after the builds for the other systems. I hope it will show up in time ...

I see that the GA builds have build number 28, are those the same builds as the early access ones (with build number 28)?

[robilad]

See #235 (comment) for alpine port status.

[robilad]

Yeah, JDK 11 build 28 was the last RC build, there were no changes, so it's the GA build.