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.