search

imagej / imagej-launcher

The ImageJ native launcher
https://imagej.net/learn/launcher
BSD 2-Clause "Simplified" License
21 stars 23 forks source link

Revise launcher discovery #72

Closed hinerm closed 3 years ago

hinerm commented 3 years ago

Removes the guess_java_version logic in favor of requiring a platform-specific /java/ subdirectory for detecting bundled javas.

The corresponding changes to logic in what was adjust_java_home_if_necessary should allow us to support any Java vendor on mac, linux and windows.

Closes #69 and https://github.com/fiji/fiji/issues/258

hinerm commented 3 years ago

@ctrueden can you test the run-java-gauntlet on OSX? It works for me on Windows and Linux.

ctrueden commented 3 years ago

I did some light cleanup of commit message, and force pushed. All commits compile with passing tests. ✅

However, the launcher does not work on macOS anymore:

$ Contents/MacOS/ImageJ-macosx
Error occurred during initialization of VM
Unable to load native library: dlopen(/Users/curtis/Applications/Fiji.app/java/macosx/adoptopenjdk-8.jdk/jre/Contents/Home/lib/libjava.dylib, 1): image not found

I'll investigate and commit a fix, probably tomorrow.

Note that on macOS, we need to link to libjli.dylib, not libjvm.dylib. Sorry I forgot about that. I have no idea where libjava.dylib is coming from—will investigate once I have dealt with some more urgent priorities today.

ctrueden commented 3 years ago

@hinerm I fixed the logic for macOS (and maybe other platforms). Aside from a lot of refactoring and debugging improvements, 32bc894aa0b57b2f3bd7e0fedc27e3791f0c8784 is what was needed. I.e.: search for libjli.dylib even when we have a java home that isn't a bundled java. Previously, the smart searching was limited to digging through only the bundled java directories, AFAICT.

There is still weirdness. Here's the end of a successful run on my system:

        find_newest complete with result: '/Library/Java/JavaVirtualMachines/adoptopenjdk-8.jdk/Contents/Home'
        set_relative_java_home:
            relative_java_home -> dk-8.jdk/Contents/Home/
        set_library_path:
            library_path is now jre/lib/jli/libjli.dylib
        Default library path (relative): jre/lib/jli/libjli.dylib
Opening Java library /Library/Java/JavaVirtualMachines/adoptopenjdk-8.jdk/Contents/Home/jre/lib/jli/libjli.dylib
get_jre_home:
    get_jre_home: Returning /Library/Java/JavaVirtualMachines/adoptopenjdk-8.jdk/Contents/Home
java.home = /Library/Java/JavaVirtualMachines/adoptopenjdk-8.jdk/Contents/Home/jre
java.vendor = AdoptOpenJDK
java.version = 1.8.0_265

See the relative_java_home? Definitely wrong. What is that even for? Clearly it's not being used here. Is it ever needed? Should we get rid of it? YOU DECIDE! 🤣

hinerm commented 3 years ago

Closed in favor of https://github.com/imagej/imagej-launcher/pull/74