-
Bug
-
Resolution: External
-
P3
-
None
-
8u51
Submitting team seening issues with locating native libraries since upgrading from a JDK 6 binary to JDK 8
@ Here is the reason: Installer executes OH/bin/diagsetup to create the ADR
@ dirs structure under ORACLE_BASE.
@ This execution creates a separate process for diagsetup which is not in
@ anyway related to the installer process. Diagsetup tool creates a separate
@ jvm of its own for performing its operation. Since the two jvms (installer's
@ and diagsetup's) are separate, the fix being made for bug 21761766 may not
@ fix the diagsetup issue. The value of java property 'java.library.path' does
@ not get passed across different jvms.
@ .
@ So the issue has to be fixed separately in diagsetup.
@ .
@ Having said this, I would like to point out that the whole issue with
@ libdbgwrapper80.so dependency on AIX needs to be fixed generically in the JDK
@ and not individually fixed in each java based tool.
@ I feel the right thing to do here is to file a bug on JDK that call to
@ standard java api for runtime.exec fails with this error. None of the
@ standard java apis should require any value to be set for
@ "java.library.path".
@ "java.library.path" should be set only for loading custom native libs, and
@ not for jdk's own native libs.
@ Here is the reason: Installer executes OH/bin/diagsetup to create the ADR
@ dirs structure under ORACLE_BASE.
@ This execution creates a separate process for diagsetup which is not in
@ anyway related to the installer process. Diagsetup tool creates a separate
@ jvm of its own for performing its operation. Since the two jvms (installer's
@ and diagsetup's) are separate, the fix being made for bug 21761766 may not
@ fix the diagsetup issue. The value of java property 'java.library.path' does
@ not get passed across different jvms.
@ .
@ So the issue has to be fixed separately in diagsetup.
@ .
@ Having said this, I would like to point out that the whole issue with
@ libdbgwrapper80.so dependency on AIX needs to be fixed generically in the JDK
@ and not individually fixed in each java based tool.
@ I feel the right thing to do here is to file a bug on JDK that call to
@ standard java api for runtime.exec fails with this error. None of the
@ standard java apis should require any value to be set for
@ "java.library.path".
@ "java.library.path" should be set only for loading custom native libs, and
@ not for jdk's own native libs.