This image is officially deprecated in favor of the
openjdk image, and will receive no further updates after 2016-12-31 (Dec 31, 2016). Please adjust your usage accordingly.
The image has been OpenJDK-specific since it was first introduced, and as of 2016-08-10 we also have an
ibmjava image, which made it even more clear that each repository should represent one upstream instead of one language stack or community, so this rename reflects that clarity appropriately.
Supported tags and respective
Where to file issues:
the Docker Community
Supported Docker versions:
the latest release (down to 1.6 on a best-effort basis)
What is Java?
Java is a concurrent, class-based, object-oriented language specifically designed to have as few implementation dependencies as possible. It is intended to allow application developers to "write once, run anywhere", meaning that code that runs on one platform does not need to be recompiled to run on another.
Java is a registered trademark of Oracle and/or its affiliates.
How to use this image
Start a Java instance in your app
The most straightforward way to use this image is to use a Java container as both the build and runtime environment. In your
Dockerfile, writing something along the lines of the following will compile and run your project:
FROM java:7 COPY . /usr/src/myapp WORKDIR /usr/src/myapp RUN javac Main.java CMD ["java", "Main"]
You can then run and build the Docker image:
$ docker build -t my-java-app . $ docker run -it --rm --name my-running-app my-java-app
Compile your app inside the Docker container
There may be occasions where it is not appropriate to run your app inside a container. To compile, but not run your app inside the Docker instance, you can write something like:
$ docker run --rm -v "$PWD":/usr/src/myapp -w /usr/src/myapp java:7 javac Main.java
This will add your current directory as a volume to the container, set the working directory to the volume, and run the command
javac Main.java which will tell Java to compile the code in
Main.java and output the Java class file to
Why is this only OpenJDK/OpenJRE?
As all of the major upstream Linux distributions are unwilling to redistribute Oracle Java in their own distribution channels, we have chosen to follow them. See references below on how each distribution does not distribute Oracle Java.
- Ubuntu stopped distributing it in the
sun-java6package when Oracle retired the "Operating System Distributor License for Java" (lists.ubuntu.com).
- Debian requires users to download the Java tar manually from oracle.com and then use
java-packageto install it (wiki.debian.net).
- The webupd8 PPA for Ubuntu and Debian requires the user to accept the Oracle license in order for their software to download and install Oracle java (webupd8.org).
- Gentoo has a fetch-restriction that requires the user to go to the Oracle website to download the Java tar manually which inclues accepting the license (wiki.gentoo.org).
- CentOS requires users to go and download the rpm provided by Oracle at java.com and thus accept the Oracle license (wiki.centos.org).
- RedHat provides instructions to add a repo that is maintained by Oracle (access.redhat.com).
java images come in many flavors, each designed for a specific use case.
This is the defacto image. If you are unsure about what your needs are, you probably want to use this one. It is designed to be used both as a throw away container (mount your source code and start the container to start your app), as well as the base to build other images off of. This tag is based off of
buildpack-deps is designed for the average user of docker who has many images on their system. It, by design, has a large number of extremely common Debian packages. This reduces the number of packages that images that derive from it need to install, thus reducing the overall size of all images on your system.
This image is based on the popular Alpine Linux project, available in the
alpine official image. Alpine Linux is much smaller than most distribution base images (~5MB), and thus leads to much slimmer images in general.
This variant is highly recommended when final image size being as small as possible is desired. The main caveat to note is that it does use musl libc instead of glibc and friends, so certain software might run into issues depending on the depth of their libc requirements. However, most software doesn't have an issue with this, so this variant is usually a very safe choice. See this Hacker News comment thread for more discussion of the issues that might arise and some pro/con comparisons of using Alpine-based images.
To minimize image size, it's uncommon for additional related tools (such as
bash) to be included in Alpine-based images. Using this image as a base, add the things you need in your own Dockerfile (see the
alpine image description for examples of how to install packages if you are unfamiliar).
View license information for the software contained in this image.