adoptopenjdk / openjdk-docker

Scripts for creating Docker images of OpenJDK binaries.

⚠ DEPRECATION NOTICE ⚠

These Dockerfiles along with their images are officially deprecated in favor of the eclipse-temurin image, and will receive no further updates after 2021-08-25 (Aug 01, 2021). Please adjust your usage accordingly.

AdoptOpenJDK and Docker

Dockerfiles and build scripts for generating Docker Images based on various AdoptOpenJDK binaries. We support both Hotspot and Eclipse OpenJ9 VMs.

Supported Architectures

• Hotspot is supported on armv7l, aarch64, ppc64le, s390x and x86_64.
• Eclipse OpenJ9 is supported on ppc64le, s390x and x86_64.

Supported OS

• Supported Linux OSes

Alpine	centos	clefos	debian	debianslim	leap	tumbleweed	ubi	ubi-minimal	ubuntu(*)
3.14	7	7	buster	buster-slim	15.3	latest	8.4	8.4	20.04

Note: Hotspot is not supported on Ubuntu 20.04 for s390x arch.

• Supported Windows OSes
  • 1809
  • ltsc2016

musl libc based Alpine Images

Starting from Java 16, hotspot builds are available natively built on musl libc instead of the regular glibc as part of the AdoptOpenJDK project. Currently these are available only for the x86_64 architecture. Accordingly we now have both regular and slim Docker Images for alpine musl based hotspot on x86_64.

Official and Non-official Images

AdoptOpenJDK Docker Images are available as both Official Images (Maintained by Docker) and Non-official Images (Maintained by AdoptOpenJDK). Please choose based on your requirements.

• Official Images are maintained by Docker and updated on every release from AdoptOpenJDK as well as when the underlying OSes are updated. Supported OSes and their versions and type of images are as below.
  • Linux
    • Ubuntu (20.04): Release
  • Windows
    • Windows Server Core (ltsc2016 and 1809): Release
• Unofficial Images are maintained by AdoptOpenJDK and updated on a nightly basis. Supported OSes and their versions and type of images are as below.
  • Linux
    • Alpine (3.14): Release, Nightly and Slim
    • CentOS (7): Release, Nightly and Slim
    • ClefOS (7): Release, Nightly and Slim
    • Debian (Buster): Release, Nightly and Slim
    • DebianSlim (Buster-slim): Release, Nightly and Slim
    • Leap (15.3): Release and Nightly
    • Tumbleweed (latest): Release and Nightly
    • UBI (8.4): Release, Nightly and Slim
    • UBI-Minimal (8.4): Release and Nightly
    • Ubuntu (20.04): Nightly and Slim

Unofficial Images: Docker Image Build Types and Associated Tags

Legend

• ${os} = alpine|debian|ubi|ubi-minimal|ubuntu|windows
• ${slim-os} = alpine|debian|ubi|ubuntu
• ${jdk-version} Eg. jdk-11.0.3_7, jdk-12.33_openj9-0.13.0
• ${jre-version} Eg. jre-11.0.3_7, jre-12.33_openj9-0.13.0

1. There are two kinds of build images
   • Release build images
     • These are release tested versions of the JDKs.
     • Associated tags:

       - latest, ${os},           ${jdk-version},      ${jdk-version}-${os}
       - jre,    ${os}-jre,       ${jre-version},      ${jre-version}-${os}
       - slim,   ${slim-os}-slim, ${jdk-version}-slim, ${jdk-version}-${slim-os}-slim
     

   • Nightly build images
     • These are nightly builds with minimal testing.
     • Associated tags:

       - nightly,      ${os}-nightly,           ${jdk-version}-${os}-nightly
       - jre-nightly,  ${os}-jre-nightly,       ${jre-version}-${os}-nightly
       - nightly-slim, ${slim-os}-nightly-slim, ${jdk-version}-${slim-os}-nightly-slim
     

2. There are two build types
   • Full build images
     • This consists of the full JDK.
     • Associated tags:

       - latest,      ${os},             ${jdk-version},         ${jdk-version}-${os}
       - jre,         ${os}-jre,         ${jre-version},         ${jre-version}-${os}
       - nightly,     ${os}-nightly,     ${jdk-version}-nightly, ${jdk-version}-${os}-nightly
       - jre-nightly, ${os}-jre-nightly, ${jre-version}-nightly, ${jre-version}-${os}-nightly
     

   • Slim build images
     • These are stripped down JDK builds that remove functionality not typically needed while running in a cloud. See the ./slim-java.sh script to see what is stripped out.
     • Associated tags:

       - slim,         ${slim-os}-slim,         ${jdk-version}-slim,         ${jdk-version}-${slim-os}-slim
       - nightly-slim, ${slim-os}-nightly-slim, ${jdk-version}-nightly-slim, ${jdk-version}-${slim-os}-nightly-slim
     

3. There are also JDK and JRE only variants
   • JDK build images
     • This consists of the full JDK.
     • Associated tags:

       - latest,       ${os},                   ${jdk-version},              ${jdk-version}-${os}
       - slim,         ${slim-os}-slim,         ${jdk-version}-slim,         ${jdk-version}-${slim-os}-slim
       - nightly,      ${os}-nightly,           ${jdk-version}-nightly,      ${jdk-version}-${os}-nightly
       - nightly-slim, ${slim-os}-nightly-slim, ${jdk-version}-nightly-slim, ${jdk-version}-${slim-os}-nightly-slim
     

   • JRE build images
     • This consists of only JRE.
     • Associated tags:

       - jre,         ${os}-jre,         ${jre-version},         ${jre-version}-${os}
       - jre-nightly, ${os}-jre-nightly, ${jre-version}-nightly, ${jre-version}-${os}-nightly
     

Here is a listing of the image sizes for the various build images and types for JDK Version 8

VMs	latest	slim	nightly	nightly-slim	alpine	alpine-slim	alpine-nightly	alpine-nightly-slim
OpenJ9	339MB	251MB	344MB	250MB	208MB	120MB	213MB	118MB
Hotspot	324MB	238MB	324MB	238MB	193MB	106MB	193MB	106MB

Notes:

1. The alpine-slim images are about 60% smaller than the latest images.
2. The Alpine Linux and the slim images are not yet TCK certified.

Build and push the Images with multi-arch support

# Steps 1-2 needs to be run on all supported arches.
# i.e aarch64, ppc64le, s390x and x86_64.

# 1. Clone this github repo
     $ git clone https://github.com/AdoptOpenJDK/openjdk-docker

# 2. Build images and tag them appropriately
     $ cd openjdk-docker
     $ ./build_all.sh

# Steps 3 needs to be run only on x86_64

# 3. build_all.sh should be run on all supported architectures to build and push images to the
#    docker registry. The images should now be available on hub.docker.com but without multi-arch
#    support. To add multi-arch support, we need to generate the right manifest lists and push them
#    to hub.docker.com. The script generate_manifest_script.sh can be used to
#    generate the right manifest commands. This needs to be run only on x86_64 after docker images
#    for all architecures have been built and made available on hub.docker.com
     $ ./update_manifest_all.sh

# We should now have the proper manifest lists pushed to hub.docker.com to support multi-arch pulls.

Info on other scripts

• update_all.sh: Script to generate all Dockerfiles.

  • update_multiarch.sh: Helper script that generates Dockerfiles for a specific Java version.

    $ ./update_multiarch.sh $version
  

  • dockerfile_functions.sh: Dockerfile content is generated from this. Update this script if you want any changes to the generated Dockerfiles.

• build_all.sh: Script to build all supported unofficial docker images on a particular architecture.

  • build_latest.sh: Helper script that builds a docker image for a specific Java version, VM and package combination.

• update_manifest_all.sh: Script that generates the multi-arch manifest for all unofficial docker images for supported/released architectures at any given time.

  • generate_manifest_script.sh: Helper script that generates the manifest for a given Java version, VM and Package combination for all supported architectures. If a build is unavailable for a supported architecture (build failed, not yet released etc), a manifest entry for that architecture will not be added.

• linter.sh: Linting dockerfiles (via hadolint).

   To lint generated dockerfiles run 
   $ ./linter.sh
  

Helper Scripts

• Run generate_latest_sums.sh to get the shasums for the latest binaries on adoptopenjdk.net

   $ ./generate_latest_sums.sh $version
  

  You should now have two files, hotspot_shasums_latest.sh and openj9_shasums_latest.sh. These will have the shasums for the latest version for each of the supported arches for hotspot and Eclipse OpenJ9 respectively.
• slim-java.sh: Script that is used to generate the slim docker images. This script strips out various aspects of the JDK that are typically not needed in a server side containerized application. This includes debug info, symbols, classes related to audio, desktop etc
• slim-java.ps1: Script that is used to generate slim docker images on Windows. This script provides the same function as the slim-java.sh script mentioned above.
• dockerhub_doc_config_update.sh: Script that generates the tag documentation for each of the unofficial AdoptOpenJDK pages on hub.docker.com and the config file for raising a PR at the Official AdoptOpenJDK git repo.

Config Files

The config dir consists of configuration files used by the scripts to determine the supported combinations of Version / OS / VM / Package / Build types and Architectures for both Official/Unofficial images as well as the corresponding tags.

• hotspot.config: Configuration for unofficial images for HotSpot.
• hotspot-official.config: Configuration for official images for HotSpot.
• openj9.config: Configuration for unofficial images for Eclipse OpenJ9.
• openj9-official.config: Configuration for official images for Eclipse OpenJ9.
• tags.config: Configuration for creating tags.

Mac OS X

Please note you'll need to upgrade bash shell on Mac OS X if you're to use our Docker images on there.

License

The Dockerfiles and associated scripts found in this project are licensed under the Apache License 2.0..

openjdk-docker's Issues

Windows docker images

Currently AdoptOpenJDK provides only linux docker images, but it would be great to have windows docker images as well. They could be included into multi-platform manifest along with existing platforms.

Note: MSFT provides wide range of docker image platforms, so it looks like supporting the latest LTSC and SAC channels would be enough.

add -XX:+IgnoreUnrecognizedVMOptions for OpenJ9 specific options

In #39, @dinogun added several OpenJ9-specific -XX command line options to the OpenJ9 docker containers via the JAVA_TOOLS_OPTIONS env var. That works just fine a lot of the time, but sometimes one installs packages that choose not to rely on OpenJDK with OpenJ9.

For example, I ran into this while installing Maven into the latest openjdk8-opendj9 docker container: several commands fail to run because apt-get install maven requires something that obstinately installs openjdk-8-jre-headless and that silly thing doesn't understand our new container options by default.

I would like to suggest that we add -XX:+IgnoreUnrecognizedVMOptions to that string of OpenJ9 options to avoid this particular problem. That has the down side that we won't discover this kind of problem quite so easily, but I think maybe it's better that the current user experience. I will optimistically assemble a pull request...

Documentation: DockerHub descriptions reference outdated versions

The DockerHub image descriptions refer to outdated image tags and at times incorrect JDK versions.

See adoptopenjdk/openjdk11:

Supported tags and respective Dockerfile links

Releases

latest, jdk-11.28, x86_64-ubuntu-jdk-11.28, aarch64-ubuntu-jdk-11.28, ppc64le-ubuntu-jdk-11.28, s390x-ubuntu-jdk-11.28 (11/jdk/ubuntu/Dockerfile.hotspot.releases.full)

Nightly

nightly, jdk11-nightly, x86_64-ubuntu-jdk11-nightly, aarch64-ubuntu-jdk11-nightly, ppc64le-ubuntu-jdk11-nightly, s390x-ubuntu-jdk11-nightly (11/jdk/ubuntu/Dockerfile.hotspot.nightly.full)

As of now, the latest release images are on version 11.0.1+13. This section also does not mention the alpine images, spawning confusion among users.

The OpenJ9 images have similar issues as well as some incorrect version references. See adoptopenjdk/openjdk11-openj9:

How to use this Image

To run a pre-built jar file with the latest Java 10 OpenJDK image, use the following commands:

FROM adoptopenjdk/openjdk11-openj9:latest
...

Is there a way to have these tags in the description(s) automatically updated when a new OpenJDK version or OS/arch is introduced?

openjdk11:alpine-nightly-slim over 3 times as big as equivalent 8 version

We about to switch from Java 8 to 11 in Docker, and have noticed that the v11 Docker images are over 3 times the size of the equivalent Java 8 images:

e.g. doing docker images for the two gives

adoptopenjdk/openjdk11 alpine-nightly-slim ca13cbe7db95 17 hours ago 248MB
adoptopenjdk/openjdk8 alpine-slim 6fbe6bede7d1 19 hours ago 74.9MB

Is there any particular reason for the image size increase ? Can this be reduced to a similar size to the Java 8 version, particularly for "slim" docker images.

Alpine JDK 10 Docker image is 'old' (supports old Java 9 class file version)

A more recent JDK 10 based image should be provided.

Original report at: adoptium/temurin-build#323

adoptopenjdk/openjdk8 Unnecessary JAVA_TOOL_OPTIONS

As of version 1.8.0_191, -XX:+UseContainerSupport has been backported to JDK8 and is enabled by default. As such -XX:+UnlockExperimentalVMOptions and -XX:+UseCGroupMemoryLimitForHeap are no longer needed in JDK8 images with this version.

docker run --rm -ti adoptopenjdk/openjdk8:jdk8u191-b12-alpine-slim /bin/sh -c "java -XX:+UnlockDiagnosticVMOptions -XX:+PrintFlagsFinal -version | grep -i UseContainerSupport"

Picked up JAVA_TOOL_OPTIONS: -XX:+UnlockExperimentalVMOptions -XX:+UseCGroupMemoryLimitForHeap
     bool UseContainerSupport                       = true                                {product}
openjdk version "1.8.0_192"
OpenJDK Runtime Environment (AdoptOpenJDK)(build 1.8.0_192-b12)
OpenJDK 64-Bit Server VM (AdoptOpenJDK)(build 25.192-b12, mixed mode)

openjdk8:alpine-slim throws NPE on Charset.availableCharsets

The current adoptopenjdk/openjdk8:alpine-slim image throws a NPE when calling Charset.availableCharsets() (this is called by Tomcat on startup). The adoptopenjdk/openjdk8:alpine (non-slim) image works with the same application code.

Here is the stacktrace:

Caused by: java.lang.NullPointerException: null
--
  | at java.nio.charset.Charset.put(Unknown Source) ~[na:1.8.0-adoptopenjdk]
  | at java.nio.charset.Charset.access$200(Unknown Source) ~[na:1.8.0-adoptopenjdk]
  | at java.nio.charset.Charset$3.run(Unknown Source) ~[na:1.8.0-adoptopenjdk]
  | at java.nio.charset.Charset$3.run(Unknown Source) ~[na:1.8.0-adoptopenjdk]
  | at java.security.AccessController.doPrivileged(Native Method) ~[na:1.8.0-adoptopenjdk]
  | at java.nio.charset.Charset.availableCharsets(Unknown Source) ~[na:1.8.0-adoptopenjdk]
  | at org.apache.tomcat.util.buf.B2CConverter.<clinit>(B2CConverter.java:49) ~[tomcat-embed-core-8.5.32.jar!/:8.5.32]

See also porscheinformatik/angular-spring-heroes/pull/10

openjdk8 download link targets latest release but should target $JAVA_VERSION

The file 8/jdk/ubuntu/Dockerfile.hotspot.releases.full contains mismatching download links.

Note: I used the referenced file as an example. It should be applied to all generated Dockerfiles/changed in dockerfile_functions.sh#L124.

The latest version downloadable is jdk8u192-b12 but the current Dockerfile is for jdk8u172-b11. The download link inside the Dockerfile points to the latest release but should depend on $JAVA_VERSION instead, that the correct binary is downloaded making the behavior of the generated Dockerfile consistent; 'When a version is specified via $JAVA_VERSION it downloads that version not the latest release'

Example for amd64

JAVA_URL="https://api.adoptopenjdk.net/v2/binary/releases/openjdk8?openjdk_impl=hotspot&os=linux&type=jdk&release=$JAVA_VERSION&heap_size=normal&arch=x64"; \      

instead of 

JAVA_URL='https://api.adoptopenjdk.net/v2/binary/releases/openjdk8?openjdk_impl=hotspot&os=linux&type=jdk&release=latest&heap_size=normal&arch=x64'; \

I swapped ' with " that $JAVA_VERSION is correctly interpolated.

https://github.com/AdoptOpenJDK/openjdk-docker/blob/master/dockerfile_functions.sh#L124 should either inject a non interpreted $JAVA_VERSION, that the variable is resolved at build time or could directly inject the version. Depending on $JAVA_VERSION feels cleaner in my opinion.

Improve README to explain difference between how DockerHub images get created and Docker images for personal use

From @dinogun

The way it works currently is that, the scripts regenerate the dockerfiles each day, so they dont use the dockerflles in those dirs
Those dirs and the dockerfiles in them are only for any external folks who want to build their own images for whatever reasons
Also as a template for how to create docker images using the adopt tarballs
Since we generage the dockerfiles everyday based on the adopt API, the docker images and tarballs will always be in sync. Else the dockerfiles may be pointing to stale data

adoptopenjdk/openjdk11-openj9/ mentions TCKs, but this is obsolete

https://hub.docker.com/r/adoptopenjdk/openjdk11-openj9/ contains a section about TCKs, however Adopt doesn't TCK certify any more.

Are the builds TCK Certified ?

This page has more information on which images are TCK certified.
``

Use of associate array in shasums*.sh assumes Bash 4+

Running docker on a Mac but trying to run the build from native fails because of the use of associate arrays (declare -A) in the shasums processing. Associate arrays were introduced in Bash 4, and MacOS is sticking to Bash 3 (for reasons known mostly to Apple).

At one point in the issues, I recall saying we were striving for Mac compatibility, but that may not be the case in these build scripts. Please opine on whether it's worth the work to adjust them back to Bash 3. (It may be as simple as using declare -a since the version numbers for the moment are all numeric.

hotspot docker images have the wrong tags

hotspot image has the wrong tag (jdk8u162-b12_openj9-0.8.0-alpine)

JDK8: JAVA_HOME and JDK folder name inside the docker image differs from image tag

While using image tag adoptopenjdk/openjdk8:jdk8u152-b16, I found that the folder name where the JAVA_HOME points to is called jdk8u144-b16 and not jdk8u152-b16

I have deleted the image from my local repo and rebuild the docker image and I still get it, also built it elsewhere and got the same issue.

$ whereis java
java: /opt/java/openjdk/jdk8u144-b01/bin/java

Temporarily I have set the folder name to jdk8u144-b16 - although JAVA_HOME does point to this folder.

$ echo $JAVA_HOME
/opt/java/openjdk/jdk8u144-b01

Basically, using image adoptopenjdk/openjdk8:jdk8u152-b16 still gives me jdk8u144-b16. Also there is no tag for version adoptopenjdk/openjdk8:jdk8u172 <== this is tag latest.

Alpine image dosen't clean up build packages

Was busy building a docker container based on adoptopenjdk/openjdk8:alpine-slim and noticed that curl was already installed when I wouldn't expect it to be. Looking at the Dockerfile I can see that build dependency packages aren't cleaned up. I expect most, if not all, of the installed packages (ca-certificates curl openssl binutils xz) to not be required in the final image.

Fixing this will require refactoring the Dockerfile as the build is across multiple RUN commands.

Add JRE docker image

I'm planning to replace OpenJDK to AdopetOpenJDK in my project that using docker.

Could you provide JRE container image like OpenJDK?

OpenJDK 11 full images should use 18.04

The OpenJDK 11 releases full Docker images use Ubuntu 16.04. While the OpenJDK 11 nightly full, releases slim, and nightly slim use Ubuntu 18.04.

Considering that the releases slim uses 18.04, and there don't appear to be major OS dependency differences between slim and full, I believe releases full should use Ubuntu 18.04.

Docker images for nightly builds

The current docker images contain the release tarballs which are only updated about once in a quarter.
(The Docker images are updated everyday to pull in the latest OS fixes, but contain the same release). Need to have docker images for the nightly builds for experimenting / testing the current codebase.

Alpine hotspot docker image - are gcc and zlib necessary ?

Hi,

looking at https://github.com/AdoptOpenJDK/openjdk-docker/blob/master/dockerfile_functions.sh#L84 and comparing to https://github.com/frol/docker-alpine-glibc/blob/master/Dockerfile it seems thac zlib and gcc are unnecesary and can be removed from hotspot version.

java.util.zip generates corrupted zip files in openjdk11-openj9:jdk-11.0.1.13-alpine-slim

Context

Recently someone reported a bug in Gradle issue tracker, after some debugging, it seems like a bug in adoptopenjdk/openjdk11-openj9:jdk-11.0.1.13-alpine-slim docker image.

Step to reproduce

zipbug.zip

There're two files in the directory. If I run the simple Java code to generate a zip in adoptopenjdk/openjdk11-openj9:jdk-11.0.1.13-alpine-slim container, it's corrupted (all tools I have tried complain it's corrupted), but it works on jdk-11.0.1_13_openj9 Mac and Ubuntu.

import java.io.BufferedOutputStream;
import java.io.File;
import java.io.FileOutputStream;
import java.io.IOException;
import java.nio.file.Files;
import java.util.Calendar;
import java.util.GregorianCalendar;
import java.util.zip.ZipEntry;
import java.util.zip.ZipOutputStream;

public class Main {
    private static final int BUFFER_SIZE = 8192;


    public static void main(String[] args) throws IOException {
	// write your code here
        ZipOutputStream outputStream = openJarOutputStream(new File("output.zip"));
        writeEntry(outputStream, "org/gradle/invocation/DefaultGradle$2.class", Files.readAllBytes(new File("DefaultGradle$2.class").toPath()));
        outputStream.finish();
        outputStream.close();
    }

    private static void writeEntry(ZipOutputStream outputStream, String name, byte[] content) throws IOException {
        ZipEntry zipEntry = newZipEntryWithFixedTime(name);
        outputStream.putNextEntry(zipEntry);
        outputStream.write(content);
        outputStream.closeEntry();
    }

    private static ZipEntry newZipEntryWithFixedTime(String name) {
        ZipEntry entry = new ZipEntry(name);
        entry.setTime(new GregorianCalendar(1980, Calendar.FEBRUARY, 1, 0, 0, 0).getTimeInMillis());
        return entry;
    }

    private static ZipOutputStream openJarOutputStream(File outputJar) {
        try {
            ZipOutputStream outputStream = new ZipOutputStream(new BufferedOutputStream(new FileOutputStream(outputJar), BUFFER_SIZE));
            outputStream.setLevel(0);
            return outputStream;
        } catch (IOException e) {
            throw new RuntimeException(e);
        }
    }
}

The console output:

# zhb @ bs-MacBook-Pro in ~/Projects/tmp/zipbug [14:23:53]
$ docker run -it -v `pwd`:/zipbug adoptopenjdk/openjdk11-openj9:jdk-11.0.1.13-alpine-slim
/ # cd zipbug/
/zipbug # ls
DefaultGradle$2.class  Main.java
/zipbug # java -version
openjdk version "11.0.1" 2018-10-16
OpenJDK Runtime Environment AdoptOpenJDK (build 11.0.1+13)
Eclipse OpenJ9 VM AdoptOpenJDK (build openj9-0.11.0, JRE 11 Linux amd64-64-Bit Compressed References 20181115_18 (JIT enabled, AOT enabled)
OpenJ9   - 090ff9dcd
OMR      - ea548a66
JCL      - d4455071ce based on jdk-11.0.1+13)
/zipbug # javac Main.java
/zipbug # java Main
/zipbug # ls -al
total 20
drwxr-xr-x    6 root     root           192 Dec  7 06:24 .
drwxr-xr-x    1 root     root          4096 Dec  7 06:24 ..
-rw-r--r--    1 root     root          1079 Dec  7 06:23 DefaultGradle$2.class
-rw-r--r--    1 root     root          1838 Dec  7 06:24 Main.class
-rw-r--r--    1 root     root          1669 Dec  7 06:23 Main.java
-rw-r--r--    1 root     root           718 Dec  7 06:24 output.zip
/zipbug # unzip output.zip -d .
Archive:  output.zip
  inflating: org/gradle/invocation/DefaultGradle$2.class
unzip: unexpected end of file
unzip: inflate error

On my Mac:

# zhb @ bs-MacBook-Pro in ~/Projects/tmp/zipbug [14:25:33] C:130
$ export JAVA_HOME=/Library/Java/JavaVirtualMachines/jdk-11.0.1+13-openj9/Contents/Home

# zhb @ bs-MacBook-Pro in ~/Projects/tmp/zipbug [14:26:13]
$ ls
DefaultGradle$2.class Main.java

# zhb @ bs-MacBook-Pro in ~/Projects/tmp/zipbug [14:26:14]
$ javac Main.java

# zhb @ bs-MacBook-Pro in ~/Projects/tmp/zipbug [14:26:18]
$ java Main

# zhb @ bs-MacBook-Pro in ~/Projects/tmp/zipbug [14:26:22]
$ unzip output.zip -d .
Archive:  output.zip
  inflating: ./org/gradle/invocation/DefaultGradle$2.class

Use Eclipse OpenJ9 in all documentation and comments

p.s. please ensure we use the full term "Eclipse OpenJ9" in documentation and comments etc. to correctly recognize the Eclipse Foundation.

Dockerfile.hotspot.releases.slim ENV JAVA_VERSION

Hi @dinogun

https://github.com/AdoptOpenJDK/openjdk-docker/blob/master/8/jdk/alpine/Dockerfile.hotspot.releases.slim#L48

says u172 but the url is downloading latest?

Docker image build request Java 9 for arm64 on alpine

Hello
I will appreciate if you could you create a docker image of Java 9
or higher for arm64 on alpine?

I tried to create the image from the Dockerfile on my own, although, once the image was created, the java command can't be running the error I'm getting is

java: ELF 64-bit LSB executable, ARM aarch64, version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux-aarch64.so.1, for GNU/Linux 3.7.0, BuildID[sha1]=9201f04d883af131e5f8bb74521502d3f2cae2bf, stripped

I checked the /lib folder and it indeed doesn't have the required file

docker run --rm ls /lib

apk
firmware
ld-linux-x86-64.so.2
ld-musl-aarch64.so.1
libc.musl-aarch64.so.1
libcrypto.so.1.0.0
libcrypto.so.42
libcrypto.so.42.0.0
libssl.so.1.0.0
libssl.so.44
libssl.so.44.0.1
libtls.so.16
libtls.so.16.0.1
libz.so.1
libz.so.1.2.11
mdev

Thanks

CentOS or distroless container suport

Please add support for CentOS.
Or better if possible "distroless" images, that would not depend on particular Linux flavor.

Some links for the distroless topic:

• https://github.com/GoogleCloudPlatform/distroless
• https://www.infoq.com/news/2017/10/choosing-container-image
• http://crunchtools.com/comparison-linux-container-images/

Incorrect PATH in nightly builds

In nightly docker images of openjdk8-openj9, jdk is present at /opt/java/openjdk/jdk8u172-b11, but the PATH is set to /opt/java/openjdk/jdk8u162-b12/bin.

$ docker run --rm -v $PWD:/tmp adoptopenjdk/openjdk8-openj9:nightly java -version
docker: Error response from daemon: oci runtime error: container_linux.go:247: starting container process caused "exec: \"java\": executable file not found in $PATH".
ERRO[0000] error getting events from daemon: context canceled

$ docker run --rm -it -v $PWD:/tmp adoptopenjdk/openjdk8-openj9:nightly
root@cff5d039aaf4:/# echo $PATH
/opt/java/openjdk/jdk8u162-b12/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin

Similarly, for openjdk9-openj9, jdk is present at /opt/java/openjdk/jdk-9.0.4+12 but PATH is set to /opt/java/openjdk/jdk-9+181/bin.

Odd failure with enable shareclasses feature

Hi guys,

I'm not sure if it is the right place to ask, but if anyone can help that would be much appreciated.

The issue is:

I've got a simple spring boot app, and I want to run it inside a Docker container.

Dockerfile:

FROM adoptopenjdk/openjdk8-openj9:alpine
RUN mkdir /opt/shareclasses
RUN mkdir /opt/app
ADD target/demo.jar app.jar
RUN mv app.jar /opt/app
CMD ["java", "-Xmx128m", "-XX:+IdleTuningGcOnIdle", "-Xtune:virtualized", "-Xscmx1024m", "-Xscmaxaot1000m","-Xshareclasses:cacheDir=/opt/shareclasses,verbose", "-jar", "/opt/app/app.jar"]

docker-compose.yml

version: '2.3'
services:
  payment:
    image: demo
    mem_limit: 160M
    environment:
     - SPRING_PROFILES_ACTIVE=dev
     - JAVA_OPTS=-Xms128m -Xmx128m
    volumes:
     - shareclasses:/opt/shareclasses

volumes:
  shareclasses:
     external: true

I have created a docker volume 'shareclasses' and a '/opt/shareclasses' folder on the host.

I can successfully start this container for the first time.
But if I want to start the second container, it always shows error.

[-Xshareclasses persistent cache enabled]
[-Xshareclasses verbose output enabled]
JVMSHRC237I Opened shared classes persistent cache sharedcc_root
JVMSHRC246I Attached shared classes persistent cache sharedcc_root
JVMSHRC765I Memory page protection on runtime data, string read-write data and partially filled pages is successfully enabled
Failed to instantiate SLF4J LoggerFactory
Reported exception:
java.lang.NoClassDefFoundError: ch.qos.logback.classic.spi.Configurator
	at ch.qos.logback.classic.util.ContextInitializer.autoConfig(ContextInitializer.java:152)
	at org.slf4j.impl.StaticLoggerBinder.init(StaticLoggerBinder.java:84)
	at org.slf4j.impl.StaticLoggerBinder.<clinit>(StaticLoggerBinder.java:55)
	at org.slf4j.LoggerFactory.bind(LoggerFactory.java:150)
	at org.slf4j.LoggerFactory.performInitialization(LoggerFactory.java:124)
	at org.slf4j.LoggerFactory.getILoggerFactory(LoggerFactory.java:412)
	at org.slf4j.LoggerFactory.getLogger(LoggerFactory.java:357)
	at org.apache.logging.slf4j.SLF4JLoggerContext.getLogger(SLF4JLoggerContext.java:39)
	at org.apache.commons.logging.LogFactory$Log4jLog.<init>(LogFactory.java:204)
	at org.apache.commons.logging.LogFactory$Log4jDelegate.createLog(LogFactory.java:166)
	at org.apache.commons.logging.LogFactory.getLog(LogFactory.java:109)
	at org.apache.commons.logging.LogFactory.getLog(LogFactory.java:99)
	at org.springframework.boot.SpringApplication.<clinit>(SpringApplication.java:198)
	at com.tranxactor.egift.Main.main(Main.java:12)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:498)
	at org.springframework.boot.loader.MainMethodRunner.run(MainMethodRunner.java:48)
	at org.springframework.boot.loader.Launcher.launch(Launcher.java:87)
	at org.springframework.boot.loader.Launcher.launch(Launcher.java:50)
	at org.springframework.boot.loader.JarLauncher.main(JarLauncher.java:51)
Caused by: java.lang.ClassNotFoundException: ch.qos.logback.classic.spi.Configurator
	at java.net.URLClassLoader.findClass(URLClassLoader.java:588)
	at java.lang.ClassLoader.loadClassHelper(ClassLoader.java:933)
	at java.lang.ClassLoader.loadClass(ClassLoader.java:878)
	at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:338)
	at java.lang.ClassLoader.loadClass(ClassLoader.java:861)
	... 22 more
Exception in thread "main" java.lang.reflect.InvocationTargetException
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:498)
	at org.springframework.boot.loader.MainMethodRunner.run(MainMethodRunner.java:48)
	at org.springframework.boot.loader.Launcher.launch(Launcher.java:87)
	at org.springframework.boot.loader.Launcher.launch(Launcher.java:50)
	at org.springframework.boot.loader.JarLauncher.main(JarLauncher.java:51)
Caused by: java.lang.NoClassDefFoundError: ch.qos.logback.classic.spi.Configurator
	at ch.qos.logback.classic.util.ContextInitializer.autoConfig(ContextInitializer.java:152)
	at org.slf4j.impl.StaticLoggerBinder.init(StaticLoggerBinder.java:84)
	at org.slf4j.impl.StaticLoggerBinder.<clinit>(StaticLoggerBinder.java:55)
	at org.slf4j.LoggerFactory.bind(LoggerFactory.java:150)
	at org.slf4j.LoggerFactory.performInitialization(LoggerFactory.java:124)
	at org.slf4j.LoggerFactory.getILoggerFactory(LoggerFactory.java:412)
	at org.slf4j.LoggerFactory.getLogger(LoggerFactory.java:357)
	at org.apache.logging.slf4j.SLF4JLoggerContext.getLogger(SLF4JLoggerContext.java:39)
	at org.apache.commons.logging.LogFactory$Log4jLog.<init>(LogFactory.java:204)
	at org.apache.commons.logging.LogFactory$Log4jDelegate.createLog(LogFactory.java:166)
	at org.apache.commons.logging.LogFactory.getLog(LogFactory.java:109)
	at org.apache.commons.logging.LogFactory.getLog(LogFactory.java:99)
	at org.springframework.boot.SpringApplication.<clinit>(SpringApplication.java:198)
	at com.tranxactor.egift.Main.main(Main.java:12)
	... 8 more
Caused by: java.lang.ClassNotFoundException: ch.qos.logback.classic.spi.Configurator
	at java.net.URLClassLoader.findClass(URLClassLoader.java:588)
	at java.lang.ClassLoader.loadClassHelper(ClassLoader.java:933)
	at java.lang.ClassLoader.loadClass(ClassLoader.java:878)
	at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:338)
	at java.lang.ClassLoader.loadClass(ClassLoader.java:861)
	... 22 more
JVMSHRC168I Total shared class bytes read=5299763. Total bytes stored=0
JVMSHRC818I Total unstored bytes due to the setting of shared cache soft max is 0. Unstored AOT bytes due to the setting of -Xscmaxaot is 0. Unstored JIT bytes due to the setting of -Xscmaxjitdata is 0.

I am pretty sure the app itself is no problem, as it can start if the shareclasses is disabled.

Any advice?

Thanks

The JDK "slim" image does not support the "--release" flag in the javac command

I am using the docker image adoptopenjdk/openjdk11:slim as a builder (compiler) in my CI enviroment and I am getting the following error message from maven

Maven 3.8.0 Compiler - Fatal error compiling: release version 11 not supported

After some debugging I found that when I run javac --help in the slim version, there are no release supported targets

But if I run it in the "full" version I get the correct targets

I supposed it is related to some file deletion during the "slim" process.

Thoughts about adding tini to docker images

Hi.

We use your OpenJ9 OpenJDK8 alpine image for our Java based service (see: https://github.com/eclipse/ditto/blob/master/services/Dockerfile ).
Did you ever think about adding tini to your Docker images?

From our experience when you want to start a single Java process in a Docker container, you also want that Docker delegates signals (like SIGTERM for example) correctly to the Java process so that this one can gracefully shutdown (e.g. via a shutdown hook).

The problem is when you start the Java process as PID 1 (when defining the EntryPoint of the docker image to do the java -jar <executable-jar-file>), the OS will "secure" this PID 1 from getting the SIGTERM signal.
Probably because the "init" process normally running which this PID should never be terminated.

tini is a small wrapper which - when used as Docker EntryPoint - forwards the signals to a wrapped process.
In this case that would be the java process.

We could of course add it to our image, but I thought I ask whether you would also like to have it in your base images.

Thanks so much.
Regards
Thomas

JDK8 java executable file not found in $PATH

When I used docker image to build my app, I found this error:
1, docker run adoptopenjdk/openjdk8-openj9:alpine java -version
2, C:\Program Files\Docker\Docker\Resources\bin\docker.exe: Error response from daemon: OCI runtime create failed: container_linux.go:348: starting container process caused "exec: "java": executable file not found in $PATH": unknown.

Verifying integrity of glibc, gcc-libs and zlib?

Hi,
As checksums are already verified for the openjdk download, I was wondering if you already considered checking also the integrity of glibc, gcc-libs and zlib downloads?

https://github.com/AdoptOpenJDK/openjdk-docker/blob/master/dockerfile_functions.sh#L92-L99

Thanks

adoptopenjdk11 build is broken: error while loading shared libraries: libjli.so

The instructions at https://hub.docker.com/r/adoptopenjdk/openjdk11/ say to run the following test command:

docker run --rm -it adoptopenjdk/openjdk11:x86_64-ubuntu-jdk11-nightly java -version

This results in the error:
java: error while loading shared libraries: libjli.so: cannot open shared object file: No such file or directory

The expected output is the java version/build info.

I've tried other tags such as 'latest' and no tag and the same error occurs.

NPE in

Update alpine linux to 3.9

Could we upgrade alpine linux from 3.8 to 3.9?
New Spring Boot 2.0.7 and 2.1.1 requires tomcat-native libraries in version 1.2.18 or above.
See:
https://pkgs.alpinelinux.org/packages?name=tomcat-native&branch=v3.9
New Spring Boot apps will not run on alpine 3.8 or lower.
See:
https://stackoverflow.com/questions/53596134/spring-boot-2-1-1-unsatisfiedlinkerror-org-apache-tomcat-jni-ssl-renegotiatepe

Problem launching JVM created with jlink in a multistage build

Here's a simple repro:
Dockerfile:

FROM adoptopenjdk/openjdk11:alpine-slim AS jlink
RUN ["jlink", "--compress=2", \
     "--module-path", "/opt/java/openjdk/jmods", \
     "--add-modules", "java.base", \
     "--output", "/jlinked"]

FROM alpine
COPY --from=jlink /jlinked /opt/jdk/
CMD ["/opt/jdk/bin/java", "-version"]

Build it:

➜  docker build .
Sending build context to Docker daemon  2.048kB
Step 1/5 : FROM adoptopenjdk/openjdk11:alpine-slim AS jlink
 ---> fe265cd564e5
Step 2/5 : RUN ["jlink", "--compress=2",      "--module-path", "/opt/java/openjdk/jmods",      "--add-modules", "java.base",      "--output", "/jlinked"]
 ---> Running in d0ba6c9e8b23
Picked up JAVA_TOOL_OPTIONS: -XX:+UseContainerSupport
Removing intermediate container d0ba6c9e8b23
 ---> 5eee259e3027
Step 3/5 : FROM alpine
 ---> 196d12cf6ab1
Step 4/5 : COPY --from=jlink /jlinked /opt/jdk/
 ---> Using cache
 ---> 037ebaa0acff
Step 5/5 : CMD ["/opt/jdk/bin/java", "-version"]
 ---> Running in 8036550b4db3
Removing intermediate container 8036550b4db3
 ---> 688097fa6a8f
Successfully built 688097fa6a8f

Run it:

➜  docker run 688097fa6a8f
standard_init_linux.go:190: exec user process caused "no such file or directory"

The executable is definitely there though. In my experience this can also be caused by missing .so

➜  docker run -it --entrypoint /bin/sh  688097fa6a8f
/ # ls /opt/jdk/bin/java
/opt/jdk/bin/java

/ # ldd /opt/jdk/bin/java
        /lib64/ld-linux-x86-64.so.2 (0x7f8695e12000)
        libz.so.1 => /lib/libz.so.1 (0x7f8695bfb000)
        libpthread.so.0 => /lib64/ld-linux-x86-64.so.2 (0x7f8695e12000)
        libjli.so => /opt/jdk/bin/../lib/jli/libjli.so (0x7f86959ea000)
        libdl.so.2 => /lib64/ld-linux-x86-64.so.2 (0x7f8695e12000)
        libc.so.6 => /lib64/ld-linux-x86-64.so.2 (0x7f8695e12000)
Error relocating /opt/jdk/bin/../lib/jli/libjli.so: __rawmemchr: symbol not found

NB1: That Error relocating issue is also present if you run ldd against the java binary in the adoptopenjdk image, and java definitely launches OK in there, so I think it's not the cause.
NB2: If I use adoptopenjdk/openjdk11:alpine-slim as the base image for the final image then it works fine - but if I can do that then there's no point using jlink - I want to cut the image size down...
NB3: musl seems to be the same in both images: ldd --version reports musl libc (x86_64) Version 1.1.19.

openjdk10-openj9 images doesn't handle SIGTERM

Hi,

I've been using openjdk:8-jre-alpine official image since 2 years ago. Now I've changed to openjdk10-openj9:alpine-slim and termination signals are not working properly so the java process doesn't terminate gracefully.

These are my files:

# Dockerfile
FROM adoptopenjdk/openjdk10-openj9:alpine-slim
ADD entrypoint.sh entrypoint.sh
RUN mkdir /opt/shareclasses
COPY target/*.jar ./app.jar
ENTRYPOINT ["./entrypoint.sh", "app.jar"]

# entrypoint.sh
#!/usr/bin/env sh

exec java -jar $JAVA_AGENT -XX:+IdleTuningGcOnIdle -Xtune:virtualized -Xscmx128m -Xscmaxaot100m -Xshareclasses:cacheDir=/opt/shareclasses $JAVA_OPTS $1 ${@:2}

I've tried with openjdk11-openj9:alpine-slim and it works so it seems an issue with jdk10 related images.

openjdk8:x86_64-ubuntu-jdk8u191-b12-slim seems to be 1.8.0_192-b12?

Platform:
Docker 18.09.2 running on AWS EC2 CentOS 7

Architecture:
x86_64

Please describe the issue that you are having with our binaries and if possible how to recreate it.
adoptopenjdk/openjdk8:x86_64-ubuntu-jdk8u191-b12-slim seems to be running 1.8.0 update 192-b12

$ docker run --rm -it adoptopenjdk/openjdk8:x86_64-ubuntu-jdk8u191-b12-slim /bin/bash
root@41dd26f924ff:/# java -version
Picked up JAVA_TOOL_OPTIONS: -XX:+UnlockExperimentalVMOptions -XX:+UseCGroupMemoryLimitForHeap
openjdk version "1.8.0_192"
OpenJDK Runtime Environment (AdoptOpenJDK)(build 1.8.0_192-b12)
OpenJDK 64-Bit Server VM (AdoptOpenJDK)(build 25.192-b12, mixed mode)
root@41dd26f924ff:/# cat /etc/os-release
NAME="Ubuntu"
VERSION="18.04.1 LTS (Bionic Beaver)"
ID=ubuntu
ID_LIKE=debian
PRETTY_NAME="Ubuntu 18.04.1 LTS"
VERSION_ID="18.04"
HOME_URL="https://www.ubuntu.com/"
SUPPORT_URL="https://help.ubuntu.com/"
BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/"
PRIVACY_POLICY_URL="https://www.ubuntu.com/legal/terms-and-policies/privacy-policy"
VERSION_CODENAME=bionic
UBUNTU_CODENAME=bionic

JDK 11 in Alpine images cannot read UTF-8 filenames

This is a subtle issue where accessing files with UTF-8 filenames from Java cannot be made to work from the alpine JDK 11 images.

To make Java access UTF-8 file names correctly, the property sun.jnu.encoding must be set to UTF-8.

However, this isn't possible in the alpine images. The reasons are that

1. From some version of the JDK after JDK 8, it isn't possible to set sun.jnu.encoding from the command line anymore to override the OS locale settings. See

https://github.com/AdoptOpenJDK/openjdk-jdk11/blob/999dbd4192d0f819cb5224f26e9e7fa75ca6f289/src/java.base/share/native/libjava/System.c#L395-L396

2. Alpine doesn't come with UTF-8 encoding installed and glibc tools are missing on alpine to install UTF-8 encodings (gliderlabs/docker-alpine#144).

This can be checked by running java -XshowSettings 2>&1 | grep jnu to show the effective setting value:

# docker run -ti --rm adoptopenjdk/openjdk11:alpine
/ # java -XshowSettings 2>&1 | grep 'jnu\|runtime.version'
    java.runtime.version = 11.0.2+9
    sun.jnu.encoding = ANSI_X3.4-1968
/ # java -XshowSettings -Dsun.jnu.encoding=UTF-8 2>&1 | grep 'jnu\|runtime.version'
    java.runtime.version = 11.0.2+9
    sun.jnu.encoding = ANSI_X3.4-1968
/ # LC_ALL=C.UTF-8 java -XshowSettings -Dsun.jnu.encoding=UTF-8 2>&1 | grep 'jnu\|runtime.version'
    java.runtime.version = 11.0.2+9
    sun.jnu.encoding = ANSI_X3.4-1968

Comparing to jdk 8:

# docker run -ti --rm adoptopenjdk/openjdk8:alpine
/ # java -XshowSettings 2>&1 | grep 'jnu\|runtime.version'
    java.runtime.version = 1.8.0_202-b08
    sun.jnu.encoding = ANSI_X3.4-1968
/ # java -XshowSettings -Dsun.jnu.encoding=UTF-8 2>&1 | grep 'jnu\|runtime.version'
    java.runtime.version = 1.8.0_202-b08
    sun.jnu.encoding = UTF-8

And comparing to the ubuntu version which has locale C.UTF-8 installed:

# docker run -ti --rm adoptopenjdk/openjdk11:latest

/ # LC_ALL=C.UTF-8 java -XshowSettings 2>&1 | grep 'jnu\|runtime.version'
e.version'f052b80:/# LC_ALL=C.UTF-8 java -XshowSettings 2>&1 | grep 'jnu\|runtime
    java.runtime.version = 11.0.2+9
    sun.jnu.encoding = UTF-8

The only workaround I found is to manually install the glibc packages as shown in gliderlabs/docker-alpine#144 (comment) to create that C.UTF-8.

Docker image for IBM Health Center

My team runs a service on Docker/Kubernetes (actually IBM Cloud Kubernetes Service). Several components make use of the OpenJ9-variant images of AdoptOpenJDK. We want to start monitoring aspects of the performance of the JVMs.

I know IBM Health Center can do this, but I don't believe there is a Docker image for Health Center. This would be much more convenient than having to build our own image, and I would have thought others might have a similar requirement (or maybe not, if I'm the first to request this ;) )

Enhancement: Alpine builds to support multiple architectures

Since OpenWhisk has adopted the AdoptOpenJDK 8 Alpine images as the basis for its core images, I've become interested in making it compatible with not amd64 architectures. The sticking point, it seems, is making glibc, libgcc, and zlib available for ppc64le, aarch64, and s390x architectures. I see two options:

1. Create a dump for tarballs of those libraries. Given their fairly infrequent release schedule this is probably the best option. (This could potentially be automated and brought into the AdoptOpenJDK farm).
2. Use a multi-stage build in the core Dockerfile (yes, I know it's script-generated) to build the libraries as we go.

For the moment, I'm going with approach 1. This issue is for information and tracking purposes.

docker adoptopenjdk/openjdk11-openj9 latest sets obsolete JAVA_VERSION

The "latest" docker file contains ENV JAVA_VERSION jdk-11+28 however this is the GA release. The last and current "latest" release is jdk-11.0.1+13 and the next release in Jan will be jdk-11.0.2+ something.

https://hub.docker.com/r/adoptopenjdk/openjdk11-openj9/

Official AdoptOpenJDK DockerHub images?

Just wondering if, now that there are some TCK certified builds being produced by AdoptOpenJDK, it makes sense to create some "Official" DockerHub images from AdoptOpenJDK so that other official images can build upon them?

@dinogun what do you think?

Missing locale UTF-8

Both Alpine and Ubuntu -based images miss the en_US.UTF-8 locale.

Under GitLab CI, Gradle can't start in deamon mode when environment variables have non-ASCII characters. See gradle/gradle#3117

A solution for the Ubuntu image would be to use

RUN apt-get install -y locales
RUN locale-gen en_US.UTF-8
ENV LANG='en_US.UTF-8' LANGUAGE='en_US:en' LC_ALL='en_US.UTF-8'

I don't know what would be the solution for Alpine.

Of course, we'd like to avoid maintaining a custom Docker image just to set the UTF-8 locale in the openjdk11 image.

Linux Docker images for 11 (Once Adopt has put out a release version)

• Alpine
• Ubuntu

Add a description on the Docker Hub page

Add description for each of the dockerhub repos at AdoptOpenJDK. See link for more details

docker image for alpine nightly build not working

Alpine nightly docker images are not working properly.
Both openjdk9 and openjdk9-openj9 throw same error when java -version is run:

$ docker run --rm -it adoptopenjdk/openjdk9-openj9:alpine-nightly java -version
java: error while loading shared libraries: libz.so.1: cannot open shared object file: No such file or directory

$ docker run --rm -it  adoptopenjdk/openjdk9:alpine-nightly java -version
java: error while loading shared libraries: libz.so.1: cannot open shared object file: No such file or directory

Adding JAVA_HOME env to the Docker images

Is it a good idea to have the base OpenJDK/OpenJ9 images export a JAVA_HOME env property?

The location of the JDK/JRE is different per container and I think it'll be easier for people to test different images if the location of the JDK can be found using a property. For example in our Dockerfile we run a keytool command to acces $JAVA_HOME/lib/security/cacerts.

Right now I have to hope the path to the JDK doesn't change, I am using the JAVA_VERSION variable to make sure a version bump will be safe by doing:

ENV JAVA_HOME /opt/java/openjdk/$JAVA_VERSION

It seems to me it is cleaner that the JAVA_HOME is provided by the Dockerfile that determines the value of the property?

Update openjdk8 image to alpine 3.7.1

Recently there was a new release of alpine:3.7.1 was done which included a backport of RCE Vulnerability (see 3.8.1 release announcement)

It contains an important security update for apk-tools which fixes a potential remote execution. A CVE is pending.

Current build are based on alpine:3.7 so I believe should pick up 3.7.1 once new release is published. However current latest release of x86_64-alpine-jdk8u172-b11 tag is 6 day old (13-Sep-2018) and is on 3.7.0

$ docker run -t adoptopenjdk/openjdk8:x86_64-alpine-jdk8u172-b11 /bin/sh -c "cat /etc/alpine-release"
3.7.0

Latest alpine image release seems to be 7 days old (12-Sep-2018) and is 3.7.1 version

$ docker run -t alpine:3.7 /bin/sh -c "cat /etc/alpine-release"
3.7.1

Can a new image be pushed such that it pick alpine:3.7.1 ?

File permission problems running Java apps as non-root

Hi all,
I'm excited to explore OpenJ9 as a more resource-friendly JVM.

I've run into a small problem trying to run my app as non-root (which is best practice and a requirement on OpenShift). I've run into stuff like "InternalError: SHA-1 not available" starting the JVM. Turns out that some JARs like jce.jar don't get the global read permission in the current images. I'm currently working with adoptopenjdk/openjdk8-openj9:latest but I suspect other variants will have similar problems.

As a work-around, I'm currently running chmod a+r -R /opt/java/openjdk/$JAVA_VERSION building my images which fixes my problem. So you may want to review file permissions of the OpenJ9 installation in the base images. Thanks!

NPE in sun.awt.FontConfiguration.getVersion(...)

We have some unit tests that create GUI components. Some of these fail with this stacktrace when using adoptopenjdk/openjdk11:latest:

        java.lang.NullPointerException
            at java.desktop/sun.awt.FontConfiguration.getVersion(FontConfiguration.java:1262)
            at java.desktop/sun.awt.FontConfiguration.readFontConfigFile(FontConfiguration.java:225)
            at java.desktop/sun.awt.FontConfiguration.init(FontConfiguration.java:107)
            at java.desktop/sun.awt.X11FontManager.createFontConfiguration(X11FontManager.java:719)
            at java.desktop/sun.font.SunFontManager$2.run(SunFontManager.java:367)
            at java.base/java.security.AccessController.doPrivileged(Native Method)
            at java.desktop/sun.font.SunFontManager.<init>(SunFontManager.java:312)
            at java.desktop/sun.awt.FcFontManager.<init>(FcFontManager.java:35)
            at java.desktop/sun.awt.X11FontManager.<init>(X11FontManager.java:56)

This is not a new issue, as seen here: docker-library/openjdk#46

This workaround also applies here: docker-library/openjdk@0f82de1 . You just have to install the package libfontconfig1 to fix this issue.

Nightly builds have the wrong PATH set for Java

$ docker run --rm -it adoptopenjdk/openjdk8:nightly java -version
docker: Error response from daemon: oci runtime error: container_linux.go:262: starting container process caused "exec: "java": executable file not found in $PATH".
ERRO[0001] error waiting for container: context canceled

$ docker run --rm -it adoptopenjdk/openjdk8-openj9:nightly java -version
docker: Error response from daemon: oci runtime error: container_linux.go:262: starting container process caused "exec: "java": executable file not found in $PATH".

JRE Docker Image

Firstly, Thank you very much for creating a Docker image for JDK-11.

Just wondering if there is a plan to have a docker image for JRE as well.