Eclipse Temurin uses "incorrect" `java.library.path` on Debian/Ubuntu

[perlun]

Summary

Eclipse Temurin uses "incorrect" java.library.path on Debian/Ubuntu

Steps to reproduce

$ apt-get install temurin-8-jdk
$ /usr/lib/jvm/temurin-8-jdk-amd64/bin/java -XshowSettings:properties -version 2>&1 | grep java.library.path -A10

Expected results

java.library.path having the same value as on Debian/Ubuntu-provided packages. The /usr/lib/x86_64-linux-gnu directory is of particular importance to our use case (more about it later in this issue).

Ubuntu 18.04

# /usr/lib/jvm/java-8-openjdk-amd64/bin/java -XshowSettings:properties -version 2>&1 | grep java.library.path -A10
    java.library.path = /usr/java/packages/lib/amd64
        /usr/lib/x86_64-linux-gnu/jni
        /lib/x86_64-linux-gnu
        /usr/lib/x86_64-linux-gnu
        /usr/lib/jni
        /lib
        /usr/lib
    java.runtime.name = OpenJDK Runtime Environment
    java.runtime.version = 1.8.0_312-8u312-b07-0ubuntu1~18.04-b07
    java.specification.name = Java Platform API Specification
    java.specification.vendor = Oracle Corporation

Debian stretch

(Cannot run this test on my bullseye system since JDK 8 is no longer available in Debian since a few years ago.)

root@4691e42881b9:/# /usr/lib/jvm/java-8-openjdk-amd64/bin/java -XshowSettings:properties -version 2>&1 | grep java.library.path -A10
    java.library.path = /usr/java/packages/lib/amd64
        /usr/lib/x86_64-linux-gnu/jni
        /lib/x86_64-linux-gnu
        /usr/lib/x86_64-linux-gnu
        /usr/lib/jni
        /lib
        /usr/lib
    java.runtime.name = OpenJDK Runtime Environment
    java.runtime.version = 1.8.0_322-8u322-b06-1~deb9u1-b06
    java.specification.name = Java Platform API Specification
    java.specification.vendor = Oracle Corporation

Actual results

$ /usr/lib/jvm/temurin-8-jdk-amd64/bin/java -XshowSettings:properties -version 2>&1 | grep java.library.path -A10
    java.library.path = /usr/java/packages/lib/amd64
        /usr/lib64
        /lib64
        /lib
        /usr/lib
    java.runtime.name = OpenJDK Runtime Environment
    java.runtime.version = 1.8.0_322-b06
    java.specification.name = Java Platform API Specification
    java.specification.vendor = Oracle Corporation
    java.specification.version = 1.8
    java.vendor = Temurin

Triaging info

Java version:

openjdk version "1.8.0_322"
OpenJDK Runtime Environment (Temurin)(build 1.8.0_322-b06)
OpenJDK 64-Bit Server VM (Temurin)(build 25.322-b06, mixed mode)

What is your operating system and platform?

Debian GNU/Linux 11 (bullseye) on x86-64.

How did you install Java?

apt-get install temurin-8-jdk

Did it work before?

Probably not. The older package adoptopenjdk-8-hotspot version 8u292-b10-3 has the exact same characteristics on Ubuntu 18.04.

Did you test with other Java versions?

Yes, see above. Package-provided JDKs both on Debian bullseye and Ubuntu 18.04 are tested to have the "correct" setting.

More details/the bigger picture

I deliberately wrote "incorrect" in quotes here since it can be argued whether the Eclipse Temurin semantics are "correct" or not in this case. Temurin just uses the OpenJDK-provided defaults as-is, AFAIK. The way Debian and Ubuntu does it is by patching the HotSpot DEFAULT_LIBPATH as can be seen in this diff: https://salsa.debian.org/java-team/openjdk-8/-/blob/master/debian/patches/hotspot-libpath-default.diff

So, why is this a problem for me/us? What we are doing is running Tomcat (with distro-provided packages from Ubuntu) on Eclipse Temurin. However, I recently noticed that Tomcat fails to pick up the "Tomcat native" libraries. Here's the content of the libtcnative-1 package on Ubuntu 18.04:

$ dpkg -L libtcnative-1 
/.
/usr
/usr/lib
/usr/lib/x86_64-linux-gnu
/usr/lib/x86_64-linux-gnu/libtcnative-1.a
/usr/lib/x86_64-linux-gnu/libtcnative-1.so.0.2.21
/usr/lib/x86_64-linux-gnu/pkgconfig
/usr/lib/x86_64-linux-gnu/pkgconfig/tcnative-1.pc
/usr/share
/usr/share/doc
/usr/share/doc/libtcnative-1
/usr/share/doc/libtcnative-1/README.Debian
/usr/share/doc/libtcnative-1/changelog.Debian.gz
/usr/share/doc/libtcnative-1/copyright
/usr/share/lintian
/usr/share/lintian/overrides
/usr/share/lintian/overrides/libtcnative-1
/usr/lib/x86_64-linux-gnu/libtcnative-1.so
/usr/lib/x86_64-linux-gnu/libtcnative-1.so.0

So, in other words: the Debian and Ubuntu distributions are built using the presumption that Java native libraries being loaded via JNI can be present in /usr/lib/x86_64-linux-gnu. As far as I know, the reason for this is to be able to support multiarch, i.e. libraries for multiple architectures to be present at the same time on the system. That's why these files are not just put in /usr/lib as usual.

Workaround

We can override -Djava.library.path in e.g. /etc/default/tomcat8, it will be picked up by the JDK. However, I still think it's worth bringing this up for discussion. There's obviously a balance between "stay close to the spirit of the upstream" vs "make it work well with the distro ecosystem at large" here, and there are perhaps other factors as well to weigh in that I'm not aware of at the moment.

Finally, thanks for a great JDK distribution! :pray:

[github-actions[bot]]

We are marking this issue as stale because it has not been updated for a while. This is just a way to keep the support issues queue manageable. It will be closed soon unless the stale label is removed by a committer, or a new comment is made.

[karianna]

Bad bot - I think we want to keep this open :-).

[jerboaa]

I think the best way to address this is by bringing the debian patch (or some variation of it upstream). For now the workaround is to set LD_LIBRARY_PATH environment variable or like the reporter said use -Djava.library.path.

LD_LIBRARY_PATH=foo java -XshowSettings:properties -version 2>&1 | grep -C10 java.library.path
Property settings:
    file.encoding = UTF-8
    file.separator = /
    java.class.path = 
    java.class.version = 61.0
    java.home = /usr/lib/jvm/java-17-openjdk-17.0.3.0.7-2.fc36.x86_64
    java.io.tmpdir = /tmp
    java.library.path = foo
        /usr/java/packages/lib
        /usr/lib64
        /lib64
        /lib
        /usr/lib
    java.runtime.name = OpenJDK Runtime Environment
    java.runtime.version = 17.0.3+7
    java.specification.name = Java Platform API Specification
    java.specification.vendor = Oracle Corporation
    java.specification.version = 17

[tellison]

Feedback from Debian folks confirms what the OP has stated - that this Path patch is applied to support multi-arch, which is a strong recommendation for toolchain / sdk type packages in Debian.

[perlun]

@karianna Whether this is a "bug" or not can of course be discussed. :slightly_smiling_face: It at least makes it impossible to use the package as drop-in-replacement for the distro-provided JDK together with libtcnative-1 and tomcat8 on Ubuntu 18.04. I'm quite certain that this is the case for more recent Ubuntu versions as well.

But it largely depends on which way Eclipse Temurin wants to go: close adherence to the upstream JDK (= few or no patches) or close adherence to distro-provided packages. I agree that being able to upstream this to the JDK would be ideal, if doable. :+1: