Missing jdk8 packages after #322

[ghollies]

Hello,
I have an application which was relying on openjdk:8u212-jdk-slim-stretch and after a recent build I have been running into

Caused by: java.lang.UnsatisfiedLinkError: /usr/local/openjdk-8/jre/lib/amd64/libfontmanager.so: libfreetype.so.6: cannot open shared object file: No such file or directory

After looking into it, the change matches up with #322 and it appears that a large number of packages are no longer present in the image.

List of removed packages using apt list | grep installed and diffing the two images

bzip2/stable,now 1.0.6-8.1 amd64 [installed]
fontconfig-config/stable,now 2.11.0-6.7 all [installed,automatic]
java-common/stable,now 0.58+deb9u1 all [installed,automatic]
libavahi-client3/stable,now 0.6.32-2 amd64 [installed,automatic]
libavahi-common-data/stable,now 0.6.32-2 amd64 [installed,automatic]
libavahi-common3/stable,now 0.6.32-2 amd64 [installed,automatic]
libbsd0/stable,now 0.8.3-1 amd64 [installed,automatic]
libcups2/stable,now 2.2.1-8+deb9u3 amd64 [installed,automatic]
libdbus-1-3/stable,now 1.10.26-0+deb9u1 amd64 [installed,automatic]
libfontconfig1/stable,now 2.11.0-6.7+b1 amd64 [installed,automatic]
libfreetype6/stable,now 2.6.3-3.2 amd64 [installed]
libgmp10/stable,now 2:6.1.2+dfsg-1 amd64 [installed,automatic]
libgnutls30/stable,now 3.5.8-5+deb9u4 amd64 [installed,automatic]
libgssapi-krb5-2/stable,now 1.15-1+deb9u1 amd64 [installed,automatic]
libhogweed4/stable,now 3.3-1+b2 amd64 [installed,automatic]
libidn11/stable,now 1.33-1 amd64 [installed,automatic]
libjpeg62-turbo/stable,now 1:1.5.1-2 amd64 [installed,automatic]
libk5crypto3/stable,now 1.15-1+deb9u1 amd64 [installed,automatic]
libkeyutils1/stable,now 1.5.9-9 amd64 [installed,automatic]
libkrb5-3/stable,now 1.15-1+deb9u1 amd64 [installed,automatic]
libkrb5support0/stable,now 1.15-1+deb9u1 amd64 [installed,automatic]
liblcms2-2/stable,stable,now 2.8-4+deb9u1 amd64 [installed,automatic]
libnettle6/stable,now 3.3-1+b2 amd64 [installed,automatic]
libnspr4/stable,now 2:4.12-6 amd64 [installed,automatic]
libnss3/stable,stable,now 2:3.26.2-1.1+deb9u1 amd64 [installed,automatic]
libpcsclite1/stable,now 1.8.20-1 amd64 [installed,automatic]
libpng16-16/stable,now 1.6.28-1+deb9u1 amd64 [installed,automatic]
libsqlite3-0/stable,now 3.16.2-5+deb9u1 amd64 [installed,automatic]
libx11-6/stable,now 2:1.6.4-3+deb9u1 amd64 [installed,automatic]
libx11-data/stable,now 2:1.6.4-3+deb9u1 all [installed,automatic]
libxau6/stable,now 1:1.0.8-1 amd64 [installed,automatic]
libxcb1/stable,now 1.12-1 amd64 [installed,automatic]
libxdmcp6/stable,now 1:1.1.2-3 amd64 [installed,automatic]
libxext6/stable,now 2:1.3.3-1+b2 amd64 [installed,automatic]
libxi6/stable,now 2:1.7.9-1 amd64 [installed,automatic]
libxrender1/stable,now 1:0.9.10-1 amd64 [installed,automatic]
libxtst6/stable,now 2:1.2.3-1 amd64 [installed,automatic]
openjdk-8-jdk-headless/stable,stable,now 8u212-b01-1~deb9u1 amd64 [installed]
openjdk-8-jre-headless/stable,stable,now 8u212-b01-1~deb9u1 amd64 [installed,automatic]
ucf/stable,now 3.0036 all [installed,automatic]
unzip/stable,now 6.0-21+deb9u1 amd64 [installed]
x11-common/stable,now 1:7.7+19 all [installed,automatic]
xz-utils/stable,now 5.2.2-1.2+b1 amd64 [installed]

In particular, fontconfig and libfreetype6 used to be present, but are now missing. I assume they were being brought in as a transitive dependency by one of the others. This change is causing my application to fail when initializing FontManager for use in a Swing application.

I see these packages being specifically included in

openjdk/8/jdk/Dockerfile

Line 13 in 2544422

fontconfig libfreetype6 \

but not in the slim version.

Questions:

1. Can we re-include fontconfig and libfreetype6 so the image is backwards compatible?
2. Without digging into each of the removed libraries I am unsure if their absence is going to cause any other java application. Are there any other known incompatibilities?
3. From the pull request in Move 8 and 11 to consume from https://adoptopenjdk.net/upstream.html #322 we were aware that it would likely cause breakages, how would people using the image be aware of change? Could we avoid pushing over existing minor versions with backwards incompatible images?

[tianon]

1. fontconfig was definitely excluded intentionally -- it's never been officially supported on the slim variants of the image, as can be seen in the test exclusions for the openjdk image: https://github.com/docker-library/official-images/blob/e7a0e9b866a114d4f6387587a97d95edad02f7f5/test/config.sh#L274-L276

2. we're not aware of other incompatibilities, but our existing integration tests are somewhat limited (we test a basic "hello world" application, uimanager for the fontconfig issue, and connecting to https://google.com to ensure CA certificates are working properly which catches a fair amount of previous issues we've seen)

3. regarding notification, the best we can offer is following either GitHub issues/PRs here or PRs with the label library/openjdk over in official-images (https://github.com/docker-library/official-images/pulls?utf8=%E2%9C%93&q=is%3Apr+label%3Alibrary%2Fopenjdk)

   regarding avoiding pushing over minor versions with backwards incompatible changes, that's the nature of the official images program -- the repo-info repository (https://github.com/docker-library/repo-info) is provided to help navigate previous versions and content addressable digests

   in this case, we knew there was a compatibility break, but we don't always have the luxury of knowing beforehand that there will be (and in this case we weren't fully sure the degree to which it would break), so we recommend users who need a stable base either consume via explicitly pinned content digests or re-tag/re-push into a separate repository to control the integration points, because these images will rebuild frequently (at least ~monthly for base image updates that pull in security fixes for packages included in the images)

[ghollies]

Thanks for the response.

We had pinned the image version more precisely in most locations, but this was a good test and found the places where we hadn't.

[mzibra]

Although this was done intentionally, I think the reasoning is wrong, fonts are not just for Windows systems, we are using Apache batik to generate pdfs, we were using this dockerimage (actually derived tomcat one) and it now fails on not finding the font library