At least verified with JDK 1.6.0_01 on Solaris 10 x86:
- It appears that the java executable re-execs itself with a modified LD_LIBRARY_PATH.
- If a Java application (run via the java executable) calls java.lang.Runtime.exec(String[]), the spawned process inherits the modified LD_LIBRARY_PATH, not the original one from the environment in which the java executable was started.
In my opinion this is a bug, as the modification of LD_LIBRARY_PATH in the java executable should be a secret implementation detail; leaking it should be avoided. This causes problems for example if the spawned process in turn wants to load a JVM, esp. a different version than the originally started java executable (which can happen for example in StarOffice/OpenOffice.org usage scenarios).
- It appears that the java executable re-execs itself with a modified LD_LIBRARY_PATH.
- If a Java application (run via the java executable) calls java.lang.Runtime.exec(String[]), the spawned process inherits the modified LD_LIBRARY_PATH, not the original one from the environment in which the java executable was started.
In my opinion this is a bug, as the modification of LD_LIBRARY_PATH in the java executable should be a secret implementation detail; leaking it should be avoided. This causes problems for example if the spawned process in turn wants to load a JVM, esp. a different version than the originally started java executable (which can happen for example in StarOffice/OpenOffice.org usage scenarios).
- duplicates
-
JDK-6367077 Purge LD_LIBRARY_PATH usage from the launcher
-
- Closed
-
- relates to
-
-
- Closed
-