Details
-
Bug
-
Resolution: Fixed
-
P2
-
11, 13, 14
Backports
Issue | Fix Version | Assignee | Priority | Status | Resolution | Resolved In Build |
---|---|---|---|---|---|---|
JDK-8228996 | 14 | Matthias Baesken | P2 | Resolved | Fixed | b09 |
JDK-8229101 | 13.0.2 | Matthias Baesken | P2 | Resolved | Fixed | b01 |
JDK-8229091 | 13.0.1 | Matthias Baesken | P2 | Resolved | Fixed | b05 |
JDK-8229400 | 11.0.5 | Matthias Baesken | P2 | Resolved | Fixed | b03 |
Description
On 30/07/2019 7:34 am, Rainer Jung wrote:
While doing Tomcat tests I noticed, that at least on SLES 12 JDK 13 and 14 EA have a lot of new runtime library dependencies.
Change fb5b3981eac with log
8222720: Provide extended VMWare/vSphere virtualization related info in the hs_error file on linux/windows x86_64
loads /usr/lib64/libguestlib.so.0 already during JVM startup. That library depends on /usr/lib64/libvmtools.so.0, which in turn depends on a lot of other libraries:
NEEDED libdnet.so.1
NEEDED libglib-2.0.so.0
NEEDED libicui18n.so.52.1
NEEDED libicuuc.so.52.1
NEEDED libpthread.so.0
NEEDED libdl.so.2
NEEDED libssl.so.1.0.0
NEEDED libcrypto.so.1.0.0
NEEDED libc.so.6
NEEDED ld-linux-x86-64.so.2
NEEDED libgcc_s.so.1
Some are not so problematic, but for instance Tomcat is able to use custom build OpenSSL libraries to replace the JSSE crypto engine with OpenSSL based one using JNI. Unfortunately the JDK is now loading libssl and libcrypto early. In case our TC OpenSSL also uses SO version 1.0.0 it will not get loaded, in case it is another version we can run into a mix of symbols resolved in the platform OpenSSL libs now loaded early and the ones provided with TC loaded later.
This is an example, why it would be good to not introduce too many native library dependencies for the JVM or make it optional in the sense of configurable during runtime. Of the above list, the icu libs, libglib and libdnet are other libs one would probably try to avoid.
While doing Tomcat tests I noticed, that at least on SLES 12 JDK 13 and 14 EA have a lot of new runtime library dependencies.
Change fb5b3981eac with log
8222720: Provide extended VMWare/vSphere virtualization related info in the hs_error file on linux/windows x86_64
loads /usr/lib64/libguestlib.so.0 already during JVM startup. That library depends on /usr/lib64/libvmtools.so.0, which in turn depends on a lot of other libraries:
NEEDED libdnet.so.1
NEEDED libglib-2.0.so.0
NEEDED libicui18n.so.52.1
NEEDED libicuuc.so.52.1
NEEDED libpthread.so.0
NEEDED libdl.so.2
NEEDED libssl.so.1.0.0
NEEDED libcrypto.so.1.0.0
NEEDED libc.so.6
NEEDED ld-linux-x86-64.so.2
NEEDED libgcc_s.so.1
Some are not so problematic, but for instance Tomcat is able to use custom build OpenSSL libraries to replace the JSSE crypto engine with OpenSSL based one using JNI. Unfortunately the JDK is now loading libssl and libcrypto early. In case our TC OpenSSL also uses SO version 1.0.0 it will not get loaded, in case it is another version we can run into a mix of symbols resolved in the platform OpenSSL libs now loaded early and the ones provided with TC loaded later.
This is an example, why it would be good to not introduce too many native library dependencies for the JVM or make it optional in the sense of configurable during runtime. Of the above list, the icu libs, libglib and libdnet are other libs one would probably try to avoid.
Attachments
Issue Links
- backported by
-
JDK-8228996 New library dependencies due to JDK-8222720
-
- Resolved
-
-
JDK-8229091 New library dependencies due to JDK-8222720
-
- Resolved
-
-
JDK-8229101 New library dependencies due to JDK-8222720
-
- Resolved
-
-
JDK-8229400 New library dependencies due to JDK-8222720
-
- Resolved
-
- relates to
-
JDK-8211846 A new switch to control verbosity of hs-err files
-
- Closed
-
-
JDK-8222720 Provide extended VMWare/vSphere virtualization related info in the hs_error file on linux/windows x86_64
-
- Resolved
-
(1 relates to)