Open perlun opened 2 years ago
github-actions[bot]
commented
2 years ago 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
commented
2 years ago Bad bot - I think we want to keep this open :-).
jerboaa
commented
2 years ago 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
commented
2 years ago 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
commented
2 years ago @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:
Summary
Eclipse Temurin uses "incorrect"
java.library.pathon Debian/UbuntuSteps to reproduce
Expected results
java.library.pathhaving the same value as on Debian/Ubuntu-provided packages. The/usr/lib/x86_64-linux-gnudirectory is of particular importance to our use case (more about it later in this issue).Ubuntu 18.04
Debian
stretch(Cannot run this test on my
bullseyesystem since JDK 8 is no longer available in Debian since a few years ago.)Actual results
Triaging info
Java version:
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-jdkDid it work before?
Probably not. The older package
adoptopenjdk-8-hotspotversion8u292-b10-3has 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_LIBPATHas can be seen in this diff: https://salsa.debian.org/java-team/openjdk-8/-/blob/master/debian/patches/hotspot-libpath-default.diffSo, 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-1package on Ubuntu 18.04: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/libas usual.Workaround
We can override
-Djava.library.pathin 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: