OpenJDK binaries depend on system zlib

[izbyshev]

• Platform and architecture: Linux/all

• Java version: 9 and above

• Variant e.g. HotSpot or OpenJ9: Tested on HotSpot

• Have you tested it with other vendors' java: Upstream (RedHat) binaries distributed by AdoptOpenJDK have this problem too

The dependency on system zlib can be easily verified on glibc-based systems:

LD_DEBUG=libs openjdk-11.0.7+10-jre/bin/java -version |& grep libz.so
     20167:     find library=libz.so.1 [0]; searching
     20167:       trying file=/home/test/openjdk-11.0.7+10-jre/bin/../lib/jli/tls/haswell/x86_64/libz.so.1
     20167:       trying file=/home/test/openjdk-11.0.7+10-jre/bin/../lib/jli/tls/haswell/libz.so.1
     20167:       trying file=/home/test/openjdk-11.0.7+10-jre/bin/../lib/jli/tls/x86_64/libz.so.1
     20167:       trying file=/home/test/openjdk-11.0.7+10-jre/bin/../lib/jli/tls/libz.so.1
     20167:       trying file=/home/test/openjdk-11.0.7+10-jre/bin/../lib/jli/haswell/x86_64/libz.so.1
     20167:       trying file=/home/test/openjdk-11.0.7+10-jre/bin/../lib/jli/haswell/libz.so.1
     20167:       trying file=/home/test/openjdk-11.0.7+10-jre/bin/../lib/jli/x86_64/libz.so.1
     20167:       trying file=/home/test/openjdk-11.0.7+10-jre/bin/../lib/jli/libz.so.1
     20167:       trying file=/home/test/openjdk-11.0.7+10-jre/bin/../lib/tls/haswell/x86_64/libz.so.1
     20167:       trying file=/home/test/openjdk-11.0.7+10-jre/bin/../lib/tls/haswell/libz.so.1
     20167:       trying file=/home/test/openjdk-11.0.7+10-jre/bin/../lib/tls/x86_64/libz.so.1
     20167:       trying file=/home/test/openjdk-11.0.7+10-jre/bin/../lib/tls/libz.so.1
     20167:       trying file=/home/test/openjdk-11.0.7+10-jre/bin/../lib/haswell/x86_64/libz.so.1
     20167:       trying file=/home/test/openjdk-11.0.7+10-jre/bin/../lib/haswell/libz.so.1
     20167:       trying file=/home/test/openjdk-11.0.7+10-jre/bin/../lib/x86_64/libz.so.1
     20167:       trying file=/home/test/openjdk-11.0.7+10-jre/bin/../lib/libz.so.1
     20167:       trying file=/lib/x86_64-linux-gnu/libz.so.1
     20167:     calling init: /lib/x86_64-linux-gnu/libz.so.1
     20167:     calling fini: /lib/x86_64-linux-gnu/libz.so.1 [0]

This dependency reduces the otherwise good OpenJDK portability for headless use cases, in particular, in chroots and containers, where zlib might not be present.

I suspect that this issue may be caused by confusing/buggy help text of the upstream configure: it claims that the bundled zlib is used by default, but in fact it uses the system one on Linux if it's present: https://hg.openjdk.java.net/jdk-updates/jdk14u/file/452c05ce40d2/make/autoconf/lib-bundled.m4#l173

Could you explicitly set --with-zlib=bundled when configuring OpenJDK?

[sxa]

Since most other distributors of OpenJDK ship with the same external zlib dependency (I've checked zulu and liberica 11 and OP has checked our upstreams) I'd be somewhat reluctant to change it, but it's certainly worth floating the idea around ...

FYI @AdoptOpenJDK/tsc

[aahlenst]

I like to hear more about the rationale.

I only see arguments against it: With bundled libraries, I've to wait for the next quarterly release to get security updates. Further, I do not understand why not having zlib in chroots/containers is a problem. There are other libraries that OpenJDK needs that aren't bundled either.

[izbyshev]

I only see arguments against it: With bundled libraries, I've to wait for the next quarterly release to get security updates

Security is a classic argument against linking dependencies statically, but its relevance depends on the goals of a particular distributor. Linux distributions usually do care about this and try to ensure that software packages use libraries provided by the distro, and OpenJDK is not an exception here. But standalone OpenJDK distributions that I know of have never been in this camp. In particular, AdoptOpenJDK doesn't set any with- options in sbin/build.sh for libraries bundled by default in OpenJDK. The same is true for other standalone distros I've used, including Zulu and Sun/Oracle ones. So I'm not sure why you bring the security argument against zlib alone.

Moreover, the docs explaining that the system zlib may be used on Linux despite what configure --help claims were committed only 14 month ago, though this was true since OpenJDK 9. So this whole situation looks more like accidental reliance on upstream defaults rather than a conscious decision, though I admit that I don't know why the upstream default has been changed.

Further, I do not understand why not having zlib in chroots/containers is a problem. There are other libraries that OpenJDK needs that aren't bundled either.

I referred to the headless use case specifically in my report. For that, the only OpenJDK dependencies in the default configuration are the C library and zlib. All other dependencies are listed in https://github.com/openjdk/jdk14u/blob/7a3bf58b8ad2c/doc/building.md#external-library-requirements and are irrelevant for this use case. At my organization we bundle OpenJDK with our software which runs in environments that we can't control or impose requirements on, and even users often can't change those environments (think chroots used to build OS distros). So zlib dependency is a problem, and in case of AdoptOpenJDK the current workaround is to put a copy of libz.so.1 into lib inside the JRE and have it picked by the dynamic loader automatically due to RPATH/RUNPATH settings in OpenJDK executables.

[sxa]

I was thinking about this recently and I'm increasingly leaning towards using the bundled zlib as far as possible for a few reasons:

• Whether the "bundled" zlib needs to be updated (i.e. whether any issue really affects java) should be done by the security team and if it warrants it then it can be patched as is seen fit based on the severity.
• It will avoid any inconsistencies in behavior (critical for compliance tests)
• At the moment we are quite inconsistent in our builds and this would be an opportunity to make things a lot more consistent.

[sxa]

Noting that this has been implemented for JDK21 at #3399
The intention is to look at doing this for other versions which will allow us to be consistent in the bundling across all platform and versions.

[izbyshev]

Thank you for the fix!