ibmjavaEstimated reading time: 9 minutes
Official IBM® SDK, Java™ Technology Edition Docker Image.
GitHub repo: https://github.com/ibmruntimes/ci.docker
Supported tags and respective
Where to get help:
the developerWorks forum for IBM Java Runtimes and SDKs
IBM Runtime Technologies
Supported Docker versions:
the latest release (down to 1.6 on a best-effort basis)
The images in this repository contain IBM® SDK, Java™ Technology Edition, version 1.8.0_sr5fp16 (8.0-5.16). See what’s new. See the license section for restrictions that relate to the use of this image. For more information about IBM® SDK, Java™ Technology Edition and API documentation as well as tutorials, recipes, and Java usage in IBM Cloud, see IBM developerWorks.
Java and all Java-based trademarks and logos are trademarks or registered trademarks of Oracle and/or its affiliates.
Eclipse OpenJ9 Images
Eclipse OpenJ9 is a high performance, scalable, Java virtual machine (JVM) implementation that represents hundreds of person-years of effort. Contributed to the Eclipse project by IBM, the OpenJ9 JVM underpins the IBM SDK, Java Technology Edition product that is a core component of many IBM Enterprise software products. Continued development of OpenJ9 at the Eclipse foundation ensures wider collaboration, fresh innovation, and the opportunity to influence the development of OpenJ9 for the next generation of Java applications. The Eclipse OpenJ9 Docker images are available through AdoptOpenJDK. They are available from here.
There are three types of Docker images here: the Software Developers Kit (SDK), and the Java Runtime Environment (JRE) and a small footprint version of the JRE (SFJ). These images can be used as the basis for custom built images for running your applications.
Small Footprint JRE
The Small Footprint JRE (SFJ) is designed specifically for web developers who want to develop and deploy cloud-based Java applications. Java tools and functions that are not required in the cloud environment, such as the Java control panel, are removed. The runtime environment is stripped down to provide core, essential function that has a greatly reduced disk and memory footprint.
Consider using Alpine Linux if you are concerned about the size of the overall image. Alpine Linux is a stripped down version of Linux that is based on musl libc and Busybox, resulting in a Docker image size of approximately 5 MB. Due to its extremely small size and reduced number of installed packages, it has a much smaller attack surface which improves security. IBM SDK has a dependency on gnu glibc, the sources can be found here. Installing this library adds an extra 8 MB to the image size. The following table compares Docker Image sizes based on the JRE version
|305 MB||184 MB||220 MB||101 MB|
Note: Alpine Linux is not an officially supported operating system for IBM® SDK, Java™ Technology Edition.
Docker Images for the following architectures are now available:
ibmjava now has multi-arch support and so the exact same commands as below works on all supported architectures. This also means that it is no longer necessary to prefix the arch with the image name as that happens auto-magically.
How to use this Image
To run a pre-built jar file with the JRE image, use the following commands:
FROM ibmjava:jre RUN mkdir /opt/app COPY japp.jar /opt/app CMD ["java", "-jar", "/opt/app/japp.jar"]
You can build and run the Docker Image as shown in the following example:
docker build -t japp . docker run -it --rm japp
If you want to place the jar file on the host file system instead of inside the container, you can mount the host path onto the container by using the following commands:
FROM ibmjava:jre CMD ["java", "-jar", "/opt/app/japp.jar"]
docker build -t japp . docker run -it -v /path/on/host/system/jars:/opt/app japp
Using the Class Data Sharing feature
IBM SDK, Java Technology Edition provides a feature called Class data sharing. This mechanism offers transparent and dynamic sharing of data between multiple Java virtual machines (JVMs) running on the same host thereby reducing the amount of physical memory consumed by each JVM instance. By providing partially verified classes and possibly pre-loaded classes in memory, this mechanism also improves the start up time of the JVM.
To enable class data sharing between JVMs that are running in different containers on the same host, a common location must be shared between containers. This requirement can be satisfied through the host or a data volume container. When enabled, class data sharing creates a named “class cache”, which is a memory-mapped file, at the common location. This feature is enabled by passing the
-Xshareclasses option to the JVM as shown in the following Dockerfile example:
FROM ibmjava:jre RUN mkdir /opt/shareclasses RUN mkdir /opt/app COPY japp.jar /opt/app CMD ["java", "-Xshareclasses:cacheDir=/opt/shareclasses", "-jar", "/opt/app/japp.jar"]
cacheDir sub-option specifies the location of the class cache. For example
/opt/sharedclasses. When sharing through the host, a host path must be mounted onto the container at the location the JVM expects to find the class cache. For example:
docker build -t japp . docker run -it -v /path/on/host/shareclasses/dir:/opt/shareclasses japp
When sharing through a data volume container, create a named data volume container that shares a volume.
docker create -v /opt/shareclasses --name classcache japp /bin/true
Then start your JVM container by using
--volumes-from flag to mount the shared volume, as shown in the following example:
docker run -it --volumes-from classcache japp
See the Websphere-Liberty image, which builds on top of this IBM docker image for Java.
ibmjava 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 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).
The Dockerfiles and associated scripts are licensed under the Apache License 2.0.
Licenses for the products installed within the images:
- IBM® SDK, Java™ Technology Edition Version 8: International License Agreement for Non-Warranted Programs.
- IBM® SDK, Java™ Technology Edition Version 9 Early Access: International License Agreement for Non-Warranted Programs.
As with all Docker images, these likely also contain other software which may be under other licenses (such as Bash, etc from the base distribution, along with any direct or indirect dependencies of the primary software being contained).
Some additional license information which was able to be auto-detected might be found in the
As for any pre-built image usage, it is the image user’s responsibility to ensure that any use of this image complies with any relevant licenses for all software contained within.library, sample, ibmjava