imagej / imagej2

Open scientific N-dimensional image processing :microscope: :sparkler:
https://imagej.net/
BSD 2-Clause "Simplified" License
1.2k stars 335 forks source link

Clean up native platform naming across ImageJ2 components #305

Open ctrueden opened 2 years ago

ctrueden commented 2 years ago

There are at least four different places where platform naming comes into play:

  1. Bare native libraries for ImageJ/ImageJ2/Fiji. The ImageJ Launcher detects the platform, and sets java.library.path to include a folder lib/<platform>, which currently supports five values: lib/win32, lib/win64, lib/macosx, lib/linux, and lib/linux-amd64. Here is the logic where that is defined.

  2. Native libraries wrapped in JAR files. The ImageJ Updater names the platforms slightly differently: jars/win32, jars/win64, jars/macosx, jars/linux32, and jars/linux64 (there is also tiger, for long-obsolete old versions of Mac OS X). Definitions are here, used in various places around the Updater code. The Updater selects the appropriate platform, marking files automatically as suitable only for the matching platform, for things in the correct lib or jars subdirectory.

  3. Naming of native classifier JARs. For example, jogl-all-2.3.2-natives-linux-i586.jar. Highly inconsistent across projects in the wild. See here and here and here for more discussion. One detail of note is that pom-scijava-base defines a property scijava.platform.arch which is generally equal to Java's os.arch except that for x86-compatible architectures (e.g. x86_64, amd64) it simplifies it down to simply the number (e.g. 64). But for non-x86 e.g. Mac M1's ARM 64-bit architecture it will be the full os.arch value e.g. arm64.

  4. Subdirectory naming convention for native-lib-loader. The native-lib-loader project enables dynamic loading of native libraries from inside JAR files, so that the JARs describe above in (3) can have their wrapped natives loaded easily. We use it in projects like FLIMLib to easily utilize native code from Java. Unfortunately, it has its own incompatible naming convention as well, distinct from (1), (2), and (3) above.

I dislike the inconsistency in naming across these four areas, and would prefer to reconcile and standardize the naming where possible, particularly now that Mac M1 machines are in the wild using ARM architecture.

imagesc-bot commented 2 years ago

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

https://forum.image.sc/t/migrating-from-fiji-clij-to-napari-pyclesperanto/54985/73

ctrueden commented 2 years ago

With scijava/pom-scijava-base@804fa6734871b402e55cce04833cd71c63d1b3cb, pom-scijava-base now defines naming conventions for javacpp- and jogl-based native classifier artifacts. With scijava/pom-scijava-base@81f583d6ac8e1b6b3eed5cd3a4c66146381be5ed, this naming is extended to support arm64/aarch64 (e.g. Mac M1).

It doesn't solve the naming discrepancies described above, but it does make dealing with item (3) in a platform-agnostic way easier from inside Maven POMs that extend pom-scijava.