Things to consider for Java 9 and beyond

[brunoborges]

After reading some of the issues, I wanted to share some thoughts on how to drive this image in the future (before it's too late) to simplify maintainability and also adoption.

Maintain only JDK images

Providing a JRE-only image is unnecessary. It does not save in substantial image size and does not add features, only removes them. There is nothing JRE can do that JDK can't.

Use a different Linux base image distribution

The current image is huge (>600MB) for something that could be smaller than 100MB if using Alpine Linux. The goal of the image should be to run most of the server-side Java applications. Users who want something different should build their own images.

See this example

The image size of OpenJDK 8 on Alpine Linux is 146.5MB

If can't change distro, trim it removing packages

The default image should contain basically only JDK and a very small Linux environment with a package manager. The environment is that makes the existing images big. If users want something else, they should apt-get / yum / apk / deb / whatever they want.

I understand the drawbacks of such changes, but it is quite obvious that the way it is right now is unsustainable. If this repository keeps going like this, next users will start to ask for images with the OpenJDK documentation or demos

m2c

[psftw]

I think a separate JRE image makes sense, and it does save ~50MB the last time I checked. As for moving to Alpine, I could see a set of image tags being created for that, but I'm against changing the existing widely used tags as it would potentially break a lot of derived images. There has been interest from folks in the Alpine community in making a set of Alpine-based image tags across a number of official repositories, which I fully support, as opposed to dropping in to a particular repository to suggest a major change when Debian is used across the board for most other images.

it is quite obvious that the way it is right now is unsustainable.

What exactly is unsustainable?

[brunoborges]

I say it is unsustainable because:

• the "official" images are not really "official" since they are not managed by the project owners of the actual software that goes into the image (for both Linux distro and Java).
• there is a great number of Java versions. And it will only increase. If someone wants a specific version, they can always download that and build their own image. Maintaining all versions on a top-level repository is unnecessary. In fact, the top-level images would do a great favour to the Java community to keep published only the latest updates of the major versions.
• the image should be about the JDK (which includes all necessary tools to all use cases). If someone wants JRE only, the user creates that by itself. Thus reducing the need to keep track of so many versions and editions.
• the image should not include a bloated Linux distro, although it is a good idea to keep a distro that has a package manager. But keeping as little installed software as possible. If someone wants curl / wget / unzip, they should extend the image and build their own.

And since OpenJDK 9 is not final, I vote for a change on that image, to use an even smaller Linux distro.

Plus, Java 9 is designed to be modular. How many images will there be for Java 9? If it continues like it is today, users will ask for a "minimum" Java 9 with core, then a "with-net-modules", then a "with-UI-modules". It will be a huge amount of unnecessary work.

Here's a question to Docker Hub maintainers
How many times each of these java tags were downloaded?
Docker Hub only shows how many pulls the entire repo got. It does not show # of downloads per tag.

[psftw]

the "official" images are not really "official" since they are not managed by the project owners of the actual software that goes into the image (for both Linux distro and Java).

Agree that it isn't really obvious who maintains the images on DockerHub and that could be improved, but it is not a requirement that upstream maintains their Docker images. The gatekeeper process, which helps ensure that nothing bad is introduced, necessitates that upstream collaborate with the official repository program administrators and cede some control over updates in any case. I think this strikes the right balance. We also make a point to reach out and invite upstreams to participate before accepting new images when not submitted by the upstream vendor directly.

If someone wants a specific version, they can always download that and build their own image ... In fact, the top-level images would do a great favour to the Java community to keep published only the latest updates of the major versions.

This is basically how it works today. Old tags are kept for historical purposes, but they are not advertised in the documentation page on DockerHub after being deprecated by a newer patch version. When a user asks for java:8, they'll always get the latest. Staying up to date and making derived images with custom software is the user's responsibility. It is not inherently unsustainable have many tags in a DockerHub repository. Back when "docker pull" acted like "-a" does today, this would have been a problem.

the image should be about the JDK

I think we'll have to agree to disagree on this one. I don't see the harm in giving the JRE option.

the image should not include a bloated Linux distro, although it is a good idea to keep a distro that has a package manager. But keeping as little installed software as possible. If someone wants curl / wget / unzip, they should extend the image and build their own.

You are describing the "-slim" variant use case, which exists in a few repositories such as Python. The role of official repositories is to provide usable out-of-the-box images, and then optionally some variants such as "-slim" based on demand. As mentioned previously, I expect there to be a bunch of Alpine-based image variants added, and I would support that, but I don't think we should abandon the Debian base that is shared across many of the Official Repositories. It provides a well-known, proven, and stable environment. Advanced users can create derived images or architect their own from scratch based on their particular needs. I would argue that the broader user community would be better served with a Debian base that includes a few extra commonly used tools and libraries. I'm not the final say on the matter, just throwing out my opinions. I don't think you've made the case why the current setup is "unsustainable" as-is, just that you would like to see a different philosophy behind the images, one which could be supported by "-slim", or perhaps "-alpine" variants.

Number of downloads is not relevant to the discussion for a number of reasons.

[jbduncan]

Just to add my own 2 cents: it's probably worth collaborating with the AdoptOpenJDK folks (https://adoptopenjdk.net/) to see if we can use their OpenJDK binaries, as I believe their efforts are as close to an official effort as it currently exists.

[yosifkit]

@jbduncan, that might be nice but I think there are a few problems: they support less architectures than Debian; they don't have a JRE only; we would have to figure out which system libraries would need to be included (like certificates and fonts that are currently apt dependencies); they currently recommend against using it for real things.

The AdoptOpenJDK Build Farm is still a Work In Progress. Please DO NOT use downloaded binaries for your production purposes.

---

As for the initial points of this issue, I think they are solved.

1. we find value in the JRE images, and now have slim variations that use the Debian provided -headless package for much smaller images

openjdk             9-jdk-slim          8b55c1bc0e1b        8 minutes ago       372MB
openjdk             9-jdk               d9e4a6558bc1        9 minutes ago       896MB
openjdk             9-jre-slim          474f27ff631f        2 minutes ago       284MB
openjdk             9-jre               ea07a67269f6        3 minutes ago       653MB
openjdk             8-jdk-slim          9a6c17e2783b        14 minutes ago      243MB
openjdk             8-jdk               f2a0d36e6942        15 minutes ago      735MB
openjdk             8-jre-slim          df0062867ea3        13 minutes ago      204MB
openjdk             8-jre               78c6b5ef0f0e        2 days ago          536MB

2. we have alpine images alongside the Debian images (initially added in add java:openjdk-8-jre-alpine #62) and openjdk:9-alpine is in progress with Create 9-alpine #100

openjdk             8-jre-alpine        b7fd89ec70e1        3 weeks ago         81.4MB
openjdk             8-jdk-alpine        53719c79dfea        3 weeks ago         101MB

3. solved by alpine and slim variants

[albuch]

@yosifkit sorry for hijacking this, but why is alpine still promoted and considered an alternative if one needs a small image even though it doesn't backport security fixes for openjdk? Shouldn't there be an info that one should not use it for production instead?