-
Notifications
You must be signed in to change notification settings - Fork 476
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
Comments
I agree, why was Stretch images dropped? |
#272 |
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, You could probably recreate a Debian-based image using multi-stage builds doing a openjdk/12/jdk/oracle/Dockerfile Lines 21 to 32 in bf1072a
The previous Debian-based images were essentially a very complicated way of running |
So I followed all those links and I'm still at a loss as to why we don't have an openjdk 12 image. |
It looks like the debian package still has bugs, https://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=openjdk-12-jre-headless;dist=unstable |
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). |
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. |
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 @Djelibeybi @robilad could I trouble you for your thoughts on this? 🙏 |
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. |
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 =) |
Please also consider that this image is the base for a whole lot of java-based official docker images, like tomcat, maven or jenkins. |
@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. |
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:
If we compare the OpenJDK 11 images, we'll see the one based on
Also, to address the concern from @metaxmx:
We have a similar package manager automatically installed, it's called |
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 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 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 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 |
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. |
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). |
@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? |
@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 |
@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. |
@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. =) |
There still seems to be some confusion, because all images in |
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. |
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). |
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. |
I'm a bit confused.
Edit: But it doesn't even have |
@renannprado can you double check you are running the right image, it should be oracle linux rather than debian. Oracle linux uses |
When you run I'd suggest checking |
I didn't know that. All good then. That makes more sense, I'll work with Thanks |
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?
The text was updated successfully, but these errors were encountered: