Reconsider AdoptOpenJDK as too buggy.
soberich opened this issue · 15 comments
We encounter severe problems with Adopt.
The fact is that all Adopt builds (8,11,12) of OpenJDK have a fonts issue.
This is very unfortunate that many teams and Docker image maintainers adopt Adopt...
Having Apache POI library for processing Excel spreadsheets in a modern (not old legacy) application any Adopt build will fail executing POI when it tries to load fonts (N.B. With NO LOGGING of an error for Java 8, only 11, 12 logs exception).
Basically anyone using Apache POI, for example, and building or, say, testing application in Docker in CI pipeline using new official Gradle Docker images will encounter this. So, for now any new tag of official Docker image contains a bug.
please see:
https://github.com/AdoptOpenJDK/openjdk-build/issues?utf8=%E2%9C%93&q=is%3Aissue+is%3Aopen+font
Should this be addressed to supply more reliable official Gradle Docker images?
Is that problem solvable by installing fontconfig package?
We tried - it didn't work for us. The last linked issue, as you can see has a long list of trials and fails of many other developers.
Do you know of an example I can use for some experimentation on my side? I want to make sure the changes to the openjdk upstream images don't also have this problem before I consider rolling back.
I'm sorry for the problems this has caused. I'm trying to do the right thing, but there are some challenges all the Java images are navigating right now...
The amazoncorretto and openjdk oracle installed the fontconfig package, and I don't see a fontconfig file in ${JAVA_HOME}/lib. The adoptopenjdk and openjdk stretch images don't have that package installed.
Also, what image were you using previously that was working? The Alpine, Debian, or Slim image?
What was the reason of this change?
It looks like AdoptOpenJDK breaks a lot of things, not having git inside is enough of a problem...
L.E. Saw the comment on the PR now.. if you need it for java12 why change it for jdk11 and lower?
Because of how the project leadership is structured. The current OpenJDK is under Oracle, updates to LTS versions of Java are under the OpenJDK Updates project, currently lead by Red Hat. This means that going forward, there won't be openjdk images for current Java versions that aren't based on Oracle Linux (since that's the only thing Oracle, as the lead of the OpenJDK project currently supports), but then once that version enters it's LTS, non-current state openjdk images can once again be made available (since at that point Oracle is no longer the lead of the project for that version of Java). If I mix and matched, using adoptopenjdk images only where an openjdk image was not available, you end up with a situation like this
11 (LTS) - openjdk or adoptopenjdk
12 - adoptopenjdk
13 - adoptopenjdk
14 - adoptopenjdk
15 - adoptopenjdk
16 - adoptopenjdk
17 (LTS) - adoptopenjdk only until Java 18, then openjdk available for Debian-based images
18 - adoptopenjdk
Another option would be to publish both AdoptOpenJDK and OpenJDK images, with different tags for each. This introduces some extra stuff for me to maintain and possibly leads to confusion of its own, so I thought it would be less confusing to just have adoptopenjdk based images across the board.
The git/ssh problem was an unintentional side-effect, and something I can fix. But I'd prefer to avoid publishing a multitude of different images with different JDK-bases if I can avoid it. If possible, I'd rather apply fixes within this image to adoptopenjdk images until they get addressed upstream (as long as it's configuration, installing additional packages, etc -- I won't recompile the JDK obviously).
See also this note: https://hub.docker.com/_/openjdk#openjdkversion-from-12-onwards-openjdkversion-oracle-and-openjdkversion-oraclelinux7
I'm still working on reproducing this. So far all the examples I've tried from conversations I've seen discussing it aren't failing for me.
This reproduced it for me, though it didn't reproduce it still failing for you with the fontconfig package installed.
import java.awt.image.BufferedImage
task fontTest {
new BufferedImage(128, 128, BufferedImage.TYPE_INT_RGB).createGraphics().drawString("test", 1, 1)
}docker run --rm -v "$PWD":/home/gradle/project -w /home/gradle/project gradle gradle --no-daemon --stacktrace fontTest
Once I installed fontconfig package, the NPE went away. I didn't have to create a fontconfig.properties file or set an LD_LIBRARY_PATH environment variable.
@keeganwitt
This didn't work for us in alpine
I'll try again today tomorrow.
RUN apk add --no-cache fontconfig ttf-dejavu && \
ln -s /usr/lib/libfontconfig.so.1 /usr/lib/libfontconfig.so && \
ln -s /lib/libuuid.so.1 /usr/lib/libuuid.so.1 && \
ln -s /lib/libc.musl-x86_64.so.1 /usr/lib/libc.musl-x86_64.so.1for 8,11,12.
Keep in mind, I'm not publishing Alpine images currently (until it is offered in AdoptOpenJDK images), and if you're experiencing this with Alpine images now, you're using older images, and that isn't an AdoptOpenJDK problem, as I have never published an Alpine image with AdoptOpenJDK.
We encountered this at runtime on general adopt image, so I was tracking which docker tags start using adopt. After a while I saw that official grade docker image have changed to adopt, so I filed this issue. Yes it was alpine non-gradle image but general one, but since grade new images are based on that the outcome is the same (e.g. tests fail)
My understanding is that the binary in OpenJDK images is not AdoptOpenJDK, but still OpenJDK, just hosted on the AdoptOpenJDK site instead of using the Debian/Alpine packages. You can see that explicitly documented in the PR: docker-library/openjdk#322
Working on reproducer now. Will try with multiple images. Post here results and reproducer by tomorrow I guess.
I think at this point the issues have been resolved. The only issue I'm aware of currently is issues in Docker Library's Jenkins builds because of architectures being added and removed from AdoptOpenJDK images depending on timing. That is being worked on I believe (docker-library/official-images#6927).