java.library.path

[ctrueden]

The ImageJ Launcher builds up a java_library_path with (on Linux) LD_LIBRARY_PATH or (on macOS) DYLD_LIBRARY_PATH, and then lib/<platform>.

• And on all platforms, it recursively adds all dirs under ${app-dir}/lib that contain at least one native library for that platform. (It even checks the contents of every candidate to make sure it really is a native library structurally...)
• And on Windows, it appends the java_library_path to PATH.
• On macOS and Linux, it uses execvp to re-execute the native launcher when the original LD_LIBRARY_PATH/DYLD_LIBRARY_PATH does not match the built-up one.
• And of course it passes -Djava.library.path=${java-library-path} to the JVM.

Should Jaunch do any/all of this? It hinges on whether the following comment is still true: "Unfortunately, ld.so only looks at LD_LIBRARY_PATH at startup, so we have to reexec after setting that variable."

From the ImageJ Launcher source code:

 * Previously the launcher modified the LD_LIBRARY_PATH appropriately for the
 * desired data model path, regardless if data models matched or not. The
 * launcher subsequently exec'ed the desired executable, in order to make the
 * LD_LIBRARY_PATH path available, for the runtime linker.
 *
 * Now, in most cases,the launcher will dlopen the target libjvm.so. All
 * required libraries are loaded by the runtime linker, using the
 * $RPATH/$ORIGIN baked into the shared libraries at compile time. Therefore,
 * in most cases, the launcher will only exec, if the data models are
 * mismatched, and will not set any environment variables, regardless of the
 * data models.
 *
 * However, if the environment contains a LD_LIBRARY_PATH, this will cause the
 * launcher to inspect the LD_LIBRARY_PATH. The launcher will check
 *  a. if the LD_LIBRARY_PATH's first component is the path to the desired
 *     libjvm.so
 *  b. if any other libjvm.so is found in any of the paths.
 * If case b is true, then the launcher will set the LD_LIBRARY_PATH to the
 * desired JRE and reexec, in order to propagate the environment.

[marktsuchida]

macOS dyld documents that it only looks at the env vars at process launch (not sure about Linux ld.so). So it would probably be useful to be able to relaunch with an altered environment (especially for ImageJ plugins that expect the current environment). On the other hand, if I were shipping an app with a fixed set of JNI libraries, I would probably want to have total control over all these paths (and may not necessarily want java.library.path to equal LD_LIBRARY_PATH; neither is necessary if the Java class knows where to find the JNI library and the JNI library contains the paths of its dependencies). Also because these paths can have security implications.

[imagesc-bot]

This issue has been mentioned on Image.sc Forum. There might be relevant details there:

https://forum.image.sc/t/jaunch-a-new-java-launcher-test-fiji-with-java-21/92058/1