Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Where's the OpenJDK 12 image? #302

Closed
markusjevringgoeuro opened this issue Apr 8, 2019 · 28 comments · Fixed by #355
Closed

Where's the OpenJDK 12 image? #302

markusjevringgoeuro opened this issue Apr 8, 2019 · 28 comments · Fixed by #355

Comments

@markusjevringgoeuro
Copy link

There are only oracle and windows images present for well, whereas for 11 there's an openjdk image and a slim image. When can we expect these for 12?

@FelicianoTech
Copy link

I agree, why was Stretch images dropped?

@yosifkit
Copy link
Member

yosifkit commented Apr 8, 2019

#272
In other words, it is only on Debian unstable: https://packages.debian.org/sid/openjdk-12-jdk

@yosifkit yosifkit closed this as completed Apr 8, 2019
@tianon
Copy link
Member

tianon commented Apr 8, 2019

See #235 for the PR which added the Oracle variants which has some of that conversation (also #212, which is highly relevant).

Essentially, at the time, openjdk-12 didn't exist in Debian (and even now only exists in Debian Unstable, which is definitely not great for folks looking for a stable base image).

You could probably recreate a Debian-based image using multi-stage builds doing a COPY --from=openjdk:12-xxx ... without too much trouble, but we have no plans to do so. You could also replicate our upstream-artifact downloading and get OpenJDK that way, which shouldn't be too difficult either:

# https://jdk.java.net/
ENV JAVA_VERSION 12
ENV JAVA_URL https://download.java.net/java/GA/jdk12/GPL/openjdk-12_linux-x64_bin.tar.gz
ENV JAVA_SHA256 b43bc15f4934f6d321170419f2c24451486bc848a2179af5e49d10721438dd56
RUN set -eux; \
\
curl -fL -o /openjdk.tgz "$JAVA_URL"; \
echo "$JAVA_SHA256 */openjdk.tgz" | sha256sum -c -; \
mkdir -p "$JAVA_HOME"; \
tar --extract --file /openjdk.tgz --directory "$JAVA_HOME" --strip-components 1; \
rm /openjdk.tgz; \

The previous Debian-based images were essentially a very complicated way of running apt-get install openjdk-NN-jre (with variants for -jdk and -headless), so you can definitely go that way also without much fanfare.

@markusjevringgoeuro
Copy link
Author

So I followed all those links and I'm still at a loss as to why we don't have an openjdk 12 image.
I know that I can create one myself, but that kind-of defeats the purpose of having official images.

@EricLemieux
Copy link

EricLemieux commented Apr 11, 2019

It looks like the debian package still has bugs,

https://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=openjdk-12-jre-headless;dist=unstable

@tianon
Copy link
Member

tianon commented Apr 12, 2019

Yes, we've had many problems with the Debian images previously, including bugs like those linked but also the fact that it has to come from Debian Unstable due to the nature of Debian releases, so when Oracle started publishing official binaries and wanted to see them officially consumed here combined with Oracle Linux, we were thrilled. For the official images, we typically focus heavily on providing an accurate representation of upstream (and what they recommend).

@markusjevringgoeuro
Copy link
Author

Why are we relying on official packages that happen to fit the distribution we happen to have chosen as an upstream? Is it not reasonable to expect that the openjdk binary distribution should "just work" on any linux distro we choose? Which should mean that we can choose any distro and just use the binary distribution of openjdk.

@tianon
Copy link
Member

tianon commented Apr 12, 2019

It comes down to upstream asked us to / recommended we should. Since we're ostensibly representing them here, we did so.

That being said, now that we've got a little distance from openjdk:11 defaulting to Debian, I'd be more open to introducing new Debian variants that aren't necessarily fully compatible with the previous ones (because that's doing to be very difficult to achieve downloading our own binaries instead of taking Debian packages), but I'd want to verify with upstream first that it's something they're OK with (given that we've got users actively requesting it).

@Djelibeybi @robilad could I trouble you for your thoughts on this? 🙏

@tianon tianon reopened this Apr 12, 2019
@tianon
Copy link
Member

tianon commented Apr 12, 2019

I do want to be very clear that if we reintroduce Debian variants for 12+ they will not match the existing Debian variants, which is a big point to hesitate on here IMO.

@markusjevringgoeuro
Copy link
Author

IMO we should be going to the simplest distro possible, so that it basically only runs java. Like the project to get openjdk running on alpine (which I know isn't ready for prime-time yet). Basically we find out what's the smallest and easiest distro we can get java on to, and then we put it there. Presumably the openjdk 12 tarball that was produced runs on something. Get that something, unpack the tarbar, add java to the path and we should be done =)

@metaxmx
Copy link

metaxmx commented Apr 12, 2019

Please also consider that this image is the base for a whole lot of java-based official docker images, like tomcat, maven or jenkins.
Having those images based on debian, allows the easy installation of required additional dependencies for compile- and runtime via the apt package manager, which is vital in a lot of setups.
Only providing an official OpenJDK image for OracleLinux without apt or a similar package manager basically breaks our whole java-based docker infrastructure, and we need to go back on rebuilding everything from vanilla debian without official (java) images - which kind of defeats the concept of official images in the first place.
I'm sure that I'm not the only one with this problem.
So please consider providing also a debian-based variant of the image, even if it is only apt-get install openjdk-NN-jre for you ...

@markusjevringgoeuro
Copy link
Author

@metaxmx While I totally get that point, for everyone who is NOT generating build images, but rather only runtime images, from the openjdk/12 images should not have to suffer, and there are likely more of those. That said, if we can achieve both goals at the same time, that would be nice.

@Djelibeybi
Copy link

From the Oracle Linux side, we're delighted to see official images based off as many flavours as the maintainers care to maintain. From our side, keep in mind that the OpenJDK built by Oracle is built on Oracle Linux internally (and is now almost identical to the Oracle JDK, so moving from an open source to a fully supported JDK is a lot simpler, if that's something of interest).

But let me address the concern from @markusjevringgoeuro:

Basically we find out what's the smallest and easiest distro we can get java on to, and then we put it there

If we compare the OpenJDK 11 images, we'll see the one based on oraclelinux:7-slim is actually the smallest (granted by only 4MB):

REPOSITORY          TAG                 IMAGE ID            CREATED             SIZE
openjdk             11-oracle           680c5ad86000        20 hours ago        464MB
openjdk             11-slim             5cc6ea6c24c4        7 days ago          468MB
openjdk             11                  0aa10063a184        7 days ago          814MB
openjdk             11-stretch          0aa10063a184        7 days ago          814MB

Also, to address the concern from @metaxmx:

Only providing an official OpenJDK image for OracleLinux without apt or a similar package manager basically breaks our whole java-based docker infrastructure

We have a similar package manager automatically installed, it's called yum. And we have https://yum.oracle.com for all your package needs, including thousands of developer-oriented packages and all updates to Oracle Linux. There is no need to pay Oracle a dime to keep all your Oracle Linux boxes up-to-date. If there are specific packages you need, I'm happy to help find them in the Oracle Linux repositories or confirm if we don't actually ship them.

@tianon
Copy link
Member

tianon commented Apr 12, 2019

To add to that, we will not be providing images for 12+ based on Debian's packages, full stop. Those packages had lots of issues, and the resulting Dockerfile really is trivial for someone else to maintain (and to maintain/track the issues that come from doing so). Please move the discussion of that elsewhere (for example, the Docker Community Forums, the Docker Community Slack, or Stack Overflow).

What's being discussed here is providing images based on the official JDK artifacts for 12+ released on https://jdk.java.net/ with a Debian base in addition to Oracle, for which I'd appreciate we keep focused on. Upstream does not distribute an official JRE package that I am aware of, nor do they have documentation for either what bits from the official downloads should be kept or what bits should be removed to create an official JRE package, so this will not involve that. (Folks wishing to create a JRE based on OpenJDK 12+ are likely better off playing with jlink anyhow to create their own custom minimal JRE via a multi-stage build or similar -- I've personally done so via the existing Oracle Linux image with a multi-stage build copying the resulting minimal JRE into a Debian-based image with great success.)

Folks who think such Debian-based images in addition to the Oracle-based images would be useful should react to this comment with a 👍 (click the image icon next to this post, then choose 👍 -- please do not spam the issue with a "+1"-style comment). This would be helpful for gauging user interest in such a thing existing (keeping in mind what I've said about jlink above and what Avi has helpfully noted about yum -- it's highly likely a Debian-based image is really not necessary here for most folks).

@markusjevringgoeuro
Copy link
Author

I don't particularly care about which base image we use. As long as we get official openjdk/12 images that are free to use in production (sorry oracle official distro), then it doesn't really matter (at least to me, as an end user) how they are built.

@Djelibeybi
Copy link

I don't particularly care about which base image we use. As long as we get official openjdk/12 images that are free to use in production (sorry oracle official distro)

Why are you sorry? The Oracle official distro of OpenJDK 12 is free to use in production as the OpenJDK is GPL (as is Oracle Linux as a collection).

@markusjevringgoeuro
Copy link
Author

@Djelibeybi really? I thought the whole point was that any jdk distribution provided by oracle was subject to the new licensing terms, which means you have to pay to use it in production. Since it's not "Development use" (as per https://www.oracle.com/technetwork/java/javase/terms/license/javase-license.html), I assumed that "production use" (the opposite of development use, in my view) was subject to license fees. It's entirely possible that I'm wrong, though. Or is this a special thing with regards to the oracle java docker images?

@Djelibeybi
Copy link

@markusjevringgoeuro No, the production-ready OpenJDK binaries released by Oracle at https://jdk.java.net are licensed under the GPLv2 with the CLASSPATH exception, as stated at the top of this page: https://jdk.java.net/12/.

These are the binaries that are used in the official openjdk:12-oracle image as you can see looking at the Dockerfile which even has GPL in the path. :)

@Djelibeybi
Copy link

@markusjevringgoeuro the license you're linking to is only applicable to the commercial JDK binaries you download from OTN, not the OpenJDK binaries from openjdk.java.net.

@markusjevringgoeuro
Copy link
Author

@Djelibeybi thank you very much for clearing that up! While I'd still like to see openjdk docker images for 12, it really opens us up to using the oracle images as well. =)

@Djelibeybi
Copy link

Djelibeybi commented Apr 17, 2019

There still seems to be some confusion, because all images in openjdk are OpenJDK images. If you want an OpenJDK 12 image, just run docker pull openjdk:12.

@pappnase99
Copy link

pappnase99 commented Apr 23, 2019

I think there is quite some misunderstanding regarding the naming of Java 12 docker images, take '12-jdk-oracle' for example. As i understand it, 'oracle' means Oracle Linux, which is free to use in production. However some people think 'oracle' refers to Oracle JDK, which is not free to use in production, that's why people keep asking for a 'free' docker image.

@tianon
Copy link
Member

tianon commented Apr 23, 2019

That's a fair point, but the OpenJDK bits we're consuming are also released by Oracle. 😅

For the avoidance of doubt: All the images here are entirely open, and there is no "proprietary" licensed Java in any image we release (unless Oracle somehow published the wrong bits to the OpenJDK project, which seems pretty unlikely; they're traditionally a very careful bunch of folks). 👍

The "Oracle" images we produce/maintain here are Oracle's officially released OpenJDK binaries (open license) on top of Oracle Linux (also open, as noted above).

@Djelibeybi
Copy link

FYI, @tianon and I have updated the documentation for the official OpenJDK image to make it clear that it's still open source: https://hub.docker.com/_/openjdk

Scroll down to the image variant section.

@renannprado
Copy link

renannprado commented Jul 22, 2019

I'm a bit confused.
I pulled openjdk:12.0.2, then ran uname -a and this is what I get:

Linux f05b4af673f9 4.19.0-5-amd64 #1 SMP Debian 4.19.37-5 (2019-06-19) x86_64 x86_64 x86_64 GNU/Linux.

Edit:

But it doesn't even have apt installed, so if I want to install something in the image, I can't.

@EricLemieux
Copy link

@renannprado can you double check you are running the right image, it should be oracle linux rather than debian.

Oracle linux uses yum rather than apt, which works a little bit differently.

@tianon
Copy link
Member

tianon commented Jul 22, 2019

When you run uname, it gives you details about the kernel (which comes from your host).

I'd suggest checking /etc/os-release.

@renannprado
Copy link

When you run uname, it gives you details about the kernel (which comes from your host).

I didn't know that.

All good then.

@EricLemieux

That makes more sense, I'll work with yum that then.

Thanks

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

9 participants