my understanding is you need to have a distributor to use openjdk someone like (oracle openjdk, adoptopenjdk) but on docker repo for openjdk how do I find out who is the distributor if I just use their reference documentation
{the code below in copied from openjdk official docker repo}
FROM openjdk:11
COPY . /usr/src/myapp
WORKDIR /usr/src/myapp
RUN javac Main.java
CMD ["java", "Main"]
moving from java 8 to java 11
It's all written there on the docker page: https://hub.docker.com/_/openjdk/
openjdk:<version>
This is the defacto image. [...] These are the suite
code names for releases of Debian and indicate which release the image
is based on. [...]
openjdk:<version> (from 12 onwards), [...]
Starting with openjdk:12
the default image as well as the -oracle and -oraclelinux7 variants
are based on the official Oracle Linux 7 image which is provided under
the GPLv2 as per the Oracle Linux End User Agreement (EULA). [...]
TL;DR: the images are maintained by the Docker community, versions < 12 ship the OpenJDK build from Debian or Alpine Linux, later versions ship the Oracle builds.
By the way, until Version including 8, the Oracle JDK was more freely available. Anyway, Linux distributions built their own binaries. The binary distributions by AdoptOpenJDK, Amazon Corretto, etc. are only there, because Oracle doesn't provide binary builds freely anymore. But you can download OpenJDK and build it yourself, if you like.
Edit: You could also ssh into the image and run java -version
Edit2: Java 7 and support
I want to address your comment on my answer. You specifically asked for Java version 7. This version is quite old (first release in 2011!) and you will not find any long term support for without paying for commercial support. Period.
This version also predates the license changes to Oracle binaries, so the whole AdoptOpenJDK argument doesn't matter.
On the OpenJDK Docker Hub page, you can see different images shipping Java 7 builds, some with Alpine Linux and some with Debian Jessie. Those are - presumably, I've only verified that for Debian - builds of the open source OpenJDK project by that distribution. So the GPL with classpath exception should be the license that applies (read: you can use it commercially).
Note that even the LTS-support for Debian Jessie ends next month: https://wiki.debian.org/LTS
That shouldn't be necessarily a problem, depending on where you want to run that image (i.e., facing the public internet vs. private intranet).
If you have to stick with such an old version of Java, you have few options (maybe taking a modern linux image and build OpenJDK yourself [that will be painful, I imagine]).
Edit3: Recent version 7 support and v8+ from AdoptOpenJdk
OK, so you clarified in your comment, that you are not actually looking for version 7 builds.
I did, however, find an up-to-date and supported build of Java 7, by Azul: https://hub.docker.com/r/azul/zulu-openjdk
But you said you're running version 8, looking to go to 11. Then I would highly recommend AdoptOpenJDK, which is currently the most popular build. They offer Docker images as well (Note: they offer different JVMs: Hotspot is the default and highly recommended, OpenJ9 is based on a development by IBM)
Related
What is the source for the OpenJDK RPMs found in Fedora distributions?
Is it safe to count on Fedora's RPMs for Java for commercial use with long term support?
Neither Oracle nor RedHat licensing seem to be necessary.
What is the source for the OpenJDK rpms found in Fedora distributions?
It's OpenJDK, which is supported.
Is it safe to count on Fedora's rpms for Java for commercial use with long term support?
If you're using an LTS version, yes.
OpenJDK Support from AdoptOpenJdk
OpenJDK support form RedHat
What is the source for the OpenJDK RPMs found in Fedora distributions?
You can use Fedora's tools on Fedora to get the sources: fedpkg clone java-11-openjdk; cd java-11-opendjk; fedpkg prep and you should end up with a directory containing the entire set of (modified) sources for OpenJDK 11.
You can also grab a source rpm (.src.rpm) from an OpenJDK build in Fedora, such as https://koji.fedoraproject.org/koji/buildinfo?buildID=1350114. That source rpm contains an archive of the entire set of sources used in Fedora.
This script is actually used to generate the source archive: https://src.fedoraproject.org/rpms/java-11-openjdk/blob/master/f/generate_source_tarball.sh. If you take a look at it, you can see that it basically grabs sources from the OpenJDK 11 Updates Project itself: http://hg.openjdk.java.net/jdk-updates/jdk11u/
Is it safe to count on Fedora's RPMs for Java for commercial use with long term support? Neither Oracle nor RedHat licensing seem to be necessary.
There's a couple of parts to this answer:
You can definitely use the Fedora packages for whatever task you want, including any commercial tasks. Fedora and OpenJDK are Free Software. They don't restrict your usage.
You definitely don't need a license from Red Hat (or Oracle) to use OpenJDK and Fedora.
If you want support, Fedora is probably the wrong place to look. Fedora is basically self-supported. Red Hat pays developers to work on OpenJDK try and fix issues as they come up. But there's no support or priority guarantees of any sort in Fedora (even if the same developers are active in both). If something breaks, you can only ask the community to help. Support (and priority in addressing bugs) is a major part of Red Hat's value proposition. That said, the developers who work on Fedora RPMs generally do a really good job.
Fedora is definitely not a Long Term Supported release. Fedora releases go out of support (meaning no more security updates for OpenJDK, unless you upgrade to a newer version of Fedora) in a year or so. If you care about a stable (as in, unchanging base), Fedora is probably the wrong tool for the job. If you want to use Fedora, you will have to upgrade every year or so, or you will lose access to security updates in OpenJDK (among other components).
If you care about long term stability and don't want to go down a RHEL route, I would suggest looking at CentOS. It has some of the same downsides as Fedora (no real support, bugs may take some time to be resolved, security updates may not be as quick) but it is maintained by the community for a longer time.
If you just care about OpenJDK binaries on non-Fedora platforms I would also suggest looking at:
OpenJDK binaries from the official OpenJDK 8 and 11 projects: https://adoptopenjdk.net/upstream.html
AdoptOpenJDK binaries built by the community: https://adoptopenjdk.net/index.html
A number of other companies, groups and organizations provide OpenJDK builds that they maintain. I can't really speak about them.
(Disclaimer: I work at Red Hat. I used to work in the team that maintains OpenJDK for Fedora but I work in a different team now.)
s#s:~$ sdk ls java
================================================================================
Available Java Versions
================================================================================
13.ea.18-open 10.0.2-zulu
12.0.1-sapmchn 10.0.2-open
12.0.1-zulu 9.0.7-zulu
12.0.1-open 9.0.4-open
12.0.1.j9-adpt 8.0.212-zulu
12.0.1.hs-adpt 8.0.212-amzn
12.0.1-librca > * 8.0.212.j9-adpt
11.0.3-sapmchn 8.0.212.hs-adpt
11.0.3-zulu 8.0.212-librca
11.0.3-amzn 8.0.202-zulufx
11.0.3.j9-adpt 7.0.222-zulu
11.0.3.hs-adpt 6.0.119-zulu
11.0.3-librca 1.0.0-rc-16-grl
11.0.2-open 1.0.0-rc-15-grl
11.0.2-zulufx 1.0.0-rc-14-grl
Why is it missing ORACLE java 8? I need it to test something, and it's available on my other PC, so I'm wondering what the problem could be.
Ubuntu 19.04.
It is no longer supported. This is the github issue for more information.
As the writer said:
The reason that we're moving to OpenJDK is that Oracle doesn't provide
Docker images that are deemed official to Docker, whereas it appears
that OpenJDK ones are as shown there. So if we're going to deploy with
OpenJDK, then we'd like to match our local dev environment as well.
I took a look at OpenJDK Docker repository and found no JRE image for Java 12. There is one for Java 11 (openjdk:11.0.2-jre), but for 12 there are only JDK images.
Q: How to use OpenJDK JRE 12 to run an application in Docker without using a full JDK image?
AdoptOpenJDK is already providing Java 12 JRE docker images (adoptopenjdk/openjdk12:jre-12.33)
AdoptOpenJDK is a Java community based effort and from its about page:
AdoptOpenJDK.net started in 2017 following years of discussions about
the general lack of an open and reproducible build & test system for
OpenJDK source across multiple platforms.
And one key point of their mission is:
Provide a reliable source of OpenJDK binaries for all platforms, for the long term future!
There is no pull request for 12 jre on OpenJdk official image repository yet (which is maintained by Docker community.
Java 11 is announced to be the most recent LTS version. So, we're trying to start new services based on this Java version.
However, the base Docker image for Java 11 is much larger than the equivalent for Java 8:
openjdk:8-jre-alpine: 84 MB
openjdk:11-jre-slim: 283 MB
(I'm considering only the official OpenJDK and the most lightweight images for each Java version.)
Deeper digging uncovered the following "things":
the openjdk:11-jre-slim image uses the base image debian:sid-slim. This brings 2 issues:
this is 60 MB larger than alpine:3.8
the Debian sid versions are unstable
the openjdk-11-jre-headless package installed in the image is 3 times larger than openjdk8-jre (inside running Docker container):
openjdk:8-jre-alpine:
/ # du -hs /usr/lib/jvm/java-1.8-openjdk/jre/lib/
57.5M /usr/lib/jvm/java-1.8-openjdk/jre/lib/
openjdk:11-jre-slim:
# du -sh /usr/lib/jvm/java-11-openjdk-amd64/lib/
179M /usr/lib/jvm/java-11-openjdk-amd64/lib/
Going deeper I discovered the "root" of this heaviness - it's the modules file of the JDK:
# ls -lhG /usr/lib/jvm/java-11-openjdk-amd64/lib/modules
135M /usr/lib/jvm/java-11-openjdk-amd64/lib/modules
So, now the questions which came:
Why is alpine not used any more as a base image for Java 11 slim images?
Why is the unstable sid version used for LTS Java images?
Why is the slim/headless/JRE package for OpenJDK 11 so large compared to the similar OpenJDK 8 package?
What is this modules file which brings 135 MB in OpenJDK 11?
UPD: as a solutions for these challenges one could use this answer: Java 11 application as docker image
Why is alpine not used any more as a base image for Java 11 slim images?
That's because, sadly, there is no official stable OpenJDK 11 build for Alpine currently.
Alpine uses musl libc, as opposed to the standard glibc used by most Linuxes out there, which means that a JVM must be compatible with musl libc for supporting vanilla Alpine. The musl OpenJDK port is being developed under OpenJDK's Portola project.
The current status is summarized on the OpenJDK 11 page:
The Alpine Linux build previously available on this page was removed as of JDK 11 GA. It’s not production-ready because it hasn’t been tested thoroughly enough to be considered a GA build. Please use the early-access JDK 12 Alpine Linux build in its place.
The only stable OpenJDK versions for Alpine currently are 7 and 8, provided by the IcedTea project.
However - if you're willing to consider other than the official OpenJDK, Azul's Zulu OpenJDK offers a compelling alternative:
It supports Java 11 on Alpine musl (version 11.0.2 as of the time of writing);
It is a certified OpenJDK build, verified using the OpenJDK TCK compliance suite;
It is free, open source and docker ready (Dockerhub).
For support availability and roadmap, see Azul support roadmap.
Update, 3/6/19: As of yesterday, openjdk11 is available in Alpine repositories! It could be grabbed on Alpine using:
apk --no-cache add openjdk11
The package is based on the jdk11u OpenJDK branch plus ported fixes from project Portola, introduced with the following PR. Kudos and huge thanks to the Alpine team.
Why is the unstable sid version used for LTS Java images?
That's a fair question / request. There's actually an open ticket for providing Java 11 on a stable Debian release:
https://github.com/docker-library/openjdk/issues/237
Update, 26/12/18: The issue has been resolved, and now the OpenJDK 11 slim image is based on stretch-backports OpenJDK 11 which was recently made available (PR link).
Why is the slim/headless/JRE package for OpenJDK 11 so large compared to the similar OpenJDK 8 package? What is this modules file which brings 135 MB in OpenJDK 11?
Java 9 introduced the module system, which is a new and improved approach for grouping packages and resources, compared to jar files. This article from Oracle gives a very detailed introduction to this feature:
https://www.oracle.com/corporate/features/understanding-java-9-modules.html
The modules file bundles all modules shipped with the JRE. The complete list of modules could be printed with java --list-modules. modules is indeed a very large file, and as commented, it contains all standard modules, and it is therefore quite bloated.
One thing to note however is that it replaces rt.jar and tools.jar which became deprecated, among other things, so when accounting for the size of modules when comparing to pre-9 OpenJDK builds, the sizes of rt.jar and tools.jar should be subtracted (they should take up some 80MB combined).
If you are considering only Official Images and your target achievement is to use the smaller JRE image available, I would suggest you to look at the official OpenJDK image openjdk:11-jre-slim-buster which is just 69.2 MB.
as for 07.2019 https://adoptopenjdk.net/ has official Alpine support for Java 11:
https://github.com/AdoptOpenJDK/openjdk-docker/blob/master/11/jdk/alpine/
https://hub.docker.com/r/adoptopenjdk/openjdk11
However, modules (jmods, jlink) still shall be considered when one assembles minimal application.
Note: slim images don't contain some modules (like java.sql) - they are excluded explicitly (https://github.com/AdoptOpenJDK/openjdk-docker/blob/21b8393b9c23f94d6921a56cce27b026537c6ca2/11/jdk/alpine/slim-java.sh#L233)
https://hub.docker.com/_/openjdk?tab=tags&page=1&name=11.0.7-jre-slim
in docker openjdk repository, slim jre 11 image is less than 70mb
Seems there are no 32-bit download packages on
Oracle's available download list.
UPDATE
Can download here:
wget --no-check-certificate --no-cookies --header "Cookie: oraclelicense=accept-securebackup-cookie" http://download.oracle.com/otn-pub/java/jdk/9+181/jdk-9_windows-x86_bin.exe
Although the 32-bit binaries for JDK9 seem to be missing from Oracle's lousy, unencrypted download page, if (after clicking "Accept License Agreement") you copy the URL of the 64-bit binaries and change x64 to x86, it will give you the 32-bit binaries.
Update: And now it's gone. Bizarre! What is Oracle playing at? They went to the effort to fix x86-specific bugs for Java 9, they explicitly said 32-bit Windows and Linux were supported, they list installation instructions for 32-bit systems, they made 32-bit builds fully available throughout the pre-release period for testing purposes, and nothing in their JDK 9 migration guide indicates that 32-bit platforms have been dropped (quite the opposite in fact: it says the -client VM command line option has been dropped so the faster -server VM is now the default for 32-bit).
So why are they suddenly hiding the release binaries?
I happened to have downloaded the Windows JDK (including JRE) and the Linux JRE for x86. I don't have the Linux JDK. There's an Oracle digital signature in the properties of the Windows exe so you can see that it's genuine. I do hope Oracle get their act together.
jdk-9_windows-x86_bin.exe: https://drive.google.com/uc?id=0B4RBD9LUbdlvUHpESXdEMmdudkE&export=download
(SHA256: 62b9bc12ea64e9edb9950b0c784a1561b8503f7384270659ad93d66f1b3b456a)
jre-9_linux-x86_bin.tar.gz: https://drive.google.com/uc?id=0B4RBD9LUbdlvb0dtOHR0eDVoQWc&export=download
(SHA256: 372fbd6d8dc70c8087c0d3547f58d593266cf26cc4f6c6698b808930b3a4018a)
jre-9_windows-x86_bin.exe
(SHA256: bbd0e75dc6360e903dd905f080e1a1d76c9c78a27d9f7dd153c6e3adc6ebc78e)
Update 2: Apparently Oracle has decided to eliminate support for x86 Java forever. They somehow finished, compiled, digitally signed, and published the Java 9 binaries by accident. The binaries still work, but presumably will not receive updates.
Update 3: Apparently Oracle has become so hateful and hostile towards Java developers that they have compelled Google to block the above downloads with a DMCA request. Nothing I can do. Sorry. If you have Java 9, you have it, and it will still work. If you don't have Java 9, well, you'll have to get creative.
Chief Java Architect Mark Reinhold in Twitter on September 25:
Sorry, but we have no plans to ship 32-bit builds of JDK 9. We’re
trying to focus more on the future than the past.
Yes, you can build your own 32-bit JDK 9 binaries.
I found a Win32 build here: https://github.com/ojdkbuild/ojdkbuild
This is a OpenJDK provided by RedHat (without support), no idea if they will provide those builds in future.
Oracle has dropped Windows 32-bit Client VM
However: The statement there "In JDK 9, the Windows 32–bit client VM is not available. Only a server VM is offered." is not even accurate, there is not even 32-bit server VM (as of Sep 27, 2017).
Update: Not just Windows, but no 32-bit for any platform is available.
Try the below link for openJDK, offers X86 (32bit) and X64 (64bit) for most java versions
https://adoptopenjdk.net/releases.html?variant=openjdk16&jvmVariant=hotspot
Dropped Windows 32–bit Client VM: In JDK 9, the Windows 32–bit client VM is not available.
data source