How exactly does Fiji’s Java runtime environment know where to find the TensorFlow JNI library file? Is it extracted from the libtensorflow_jni-<VERSION>.jar to a temporary directory and then fed as an argument to the JRE during Fiji’s startup?
I am currently troubleshooting a problem in which a library that I have written runs perfectly when used in one of my Fiji plugins but fails as a Micro-Manager plugin. My current hypothesis is that Micro-Manager is unable find the TensorFlow JNI library since I am seeing
java.lang.NoSuchMethodError's in the Micro-Manager core logs and because it appears that all my .jar dependencies are in place.
Since my library works in Fiji without any special handling of the TensorFlow JNI library, this raises the question as to how Fiji knows where the library is located. In Fiji, the JNI libraries for Windows, Mac, and Linux are all located in jars/libtensorflow_jni-<VERSION>.jar. However, the TensorFlow documentation states that the JRE must be launched with an argument that specifies where the .jni library is located.
I’m really just curious about whether Fiji is doing some magic behind the scenes to get the library out of the .jar file and then feed it to the JRE.
As it turns out, Micro-Manager is finding the TensorFlow JNI, so the
java.lang.NoSuchErrorMethod is being caused by something else.
Problem solved. The ultimate cause of the inconsistency between Micro-Manager and Fiji was a subtle TensorFlow version conflict; when I constructed the uber-jar for Micro-Manager, Maven placed the incorrect version of TensorFlow into the uber-jar.