Please provide prerequisites and instructions for building imagej-launcher on Windows 10.

From @rasband:

The ImageJ launcher does not work with ImageJ1 on OS X because it assumes the plugins directory is in the ImageJ.app directory when it is actually in the same directory as ImageJ.app.

We should have a launcher-name variable that is set in each platform-specific profile. We can then have a copy step bound to the package phase that renames any created binary to the correct launcher name (instead of "imagej-launcher"). This step should probably also make the launcher executable.

In many scenarios on Windows, it is necessary to pass the --console flag so that the console it attached correctly. Otherwise, no output will ever been shown.

This flag is unfortunate, and it would be best if we could get rid of it completely. But barring that, let's at least be smarter about automatically enabling the console attach feature in circumstances where it is known to be necessary, such as with --headless.

See also #10, #11.

We received a report in the testing of ImageJ-MATLAB that launching from within MATLAB can replace the MATLAB icon with a Fiji icon.

I am hazy on the details but I thought the aggressive icon rewriting was a fix for OSX? I wasn't able to reproduce the issue personally on Ubuntu 14.04.

That said, if we can reproduce and isolate the issue, it would be great to be able to check if we're being called from another app or not, and avoid rewriting the icon in the former case.

The guess_java_version method encodes the major, minor, patch and build versions into 8-bit chunks of a 32-bit int. If any of these values exceeds 255, it would overflow. In the case of the build version, nothing consumes it, so maybe this is not a problem. But filing here just in case.

The OSX profiles try to link against Java 6. However, as of El Capitan, the expected Headers directory is no longer present in Apple Java 6 installs.

Instead, we should update the profiles to check for the "include" directory that is used in java 7+.

If I try to run ImageJ with a PATH that has empty values, e.g.:

PATH=/usr/local/sbin::/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin ./ImageJ-macosx

(Notice the "::" after /usr/local/sbin)
The result is:

Segmentation fault: 11

If I run Fiji.app with the same PATH under Mac OS X, I get the following in the Error Report:

Exception Type:  EXC_BAD_ACCESS (SIGSEGV)
Exception Codes: KERN_INVALID_ADDRESS at 0x0000000000000000

Hi @ctrueden, and @hinerm ,

thanks a lot for working on the launcher!

As you're deploying the launcher these days anyway, would it be possible to make one which has a Fiji icon compiled into it?

At the moment, the program changes its icon on Windows when being pinned to the task bar. As many users pin the program there, they never see the Fiji logo. :-(

Before pinning:

After pinning:

I'm speculating this would change if this file would be replaced:
https://github.com/imagej/imagej-launcher/blob/master/logo/ImageJ.ico

by this one:
https://github.com/fiji/fiji/blob/master/images/fiji.ico

Let me know if I can help!

Cheers,
Robert

The new Java splash (#53) currently looks in Fiji.app/images/logo.png for the logo to show in the splash screen. This should be improved in a future version s.t. the splash is composed of the new ImageJ2 logo (large, main logo) and all the logos found in e.g. Fiji.app/logos/* in smaller versions. This would allow to see which update sites are activated (if they ship a custom logo) during startup.

The laucher is not able to pick up the JRE shipped with the latest Fiji version, see this issue.

To get the most recent launcher version, we used the trim-the-fat branch (which should probably be finished and merged, as far as I understood?) and deleted this commit, otherwise it would not build. The resulting Imagej-linux64 binary prints this message:

Could not load Java library '/media/data/Programs/Fiji.app/java/linux-amd64/jdk1.8.0_172/jre//lib/server/libjvm.so': /media/data/Programs/Fiji.app/java/linux-amd64/jdk1.8.0_172/jre//lib/server/libjvm.so: cannot open shared object file: No such file or directory
Warning: falling back to System JVM

It tries to use lib/server/libjvm.so instead of lib/amd64/server/libjvm.so which would be the correct path.

I think I was able to track it down to this line where it should pick lib/amd64/server/libjvm.so but used lib/server/libjvm.so instead.

When determining whether an option belongs to Java, or to ImageJ, the current strategy is to pick out the "known ImageJ" options. But with ImageJ2 that list got much more open-ended due to the ConsoleService. So let's invert the logic, and instead pick out the options known to be Java options, and assume the rest are for ImageJ.

By default, it seems like all the useful debug information is now being logged at level=info. This means it typically is not visible, e.g. when running --update update or --update upload-complete-site --simulate ImageJ.

It would be nice if we forced the scijava.log.level to be info when running these commands

Currently the command line options are parsed AFTER java detection, which means that any debugging output during java detection is always skipped, even if setting the debug flag.

Based on this report it looks like trying to set the Java executable (and potentially Java path?) via ImageJ.cfg results in a search failure and fallback to system Java.

I am not sure we actually want to guarantee behavior from ImageJ.cfg but our launcher should either:

• Honor the .cfg settings. If they were working before they should continue to work.
• Or suppress the setting and notify the user of that suppression

The launcher should pass -Dscijava.context.strict=false by default, to make it more likely for quasi-broken configurations to start up successfully, such that the updater can be launched to fix things.

When a classpath is specified on windows 10, either on command line or in ImageJ.cfg, Launcher converts it to DOS path (short names with ~). That converted path is not recognized by Java (tested with 1.8.0_74 and 1.8.0_92).

Please leave screenshots with a note on the operating system used

The splash screen on OS X is hard coded to /System/Library/Java/JavaVirtualMachines. This is wrong—it should look for libsplashscreen.dylib (or libsplashscreen.jnilib in older cases) in the chosen JRE's lib folder; e.g.:

$ find /Library/Java/JavaVirtualMachines -name 'libsplashscreen.*'
/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Libraries/libsplashscreen.jnilib
/Library/Java/JavaVirtualMachines/1.6.0_45-b06-451.jdk/Contents/Libraries/libsplashscreen.jnilib
/Library/Java/JavaVirtualMachines/1.6.0_65-b14-462.jdk/Contents/Libraries/libsplashscreen.jnilib
/Library/Java/JavaVirtualMachines/jdk1.7.0_21.jdk/Contents/Home/jre/lib/libsplashscreen.dylib
/Library/Java/JavaVirtualMachines/jdk1.7.0_45.jdk/Contents/Home/jre/lib/libsplashscreen.dylib
/Library/Java/JavaVirtualMachines/jdk1.7.0_80.jdk/Contents/Home/jre/lib/libsplashscreen.dylib
/Library/Java/JavaVirtualMachines/jdk1.8.0.jdk/Contents/Home/jre/lib/libsplashscreen.dylib
/Library/Java/JavaVirtualMachines/jdk1.8.0_11.jdk/Contents/Home/jre/lib/libsplashscreen.dylib
/Library/Java/JavaVirtualMachines/jdk1.8.0_45.jdk/Contents/Home/jre/lib/libsplashscreen.dylib
/Library/Java/JavaVirtualMachines/jdk1.8.0_66.jdk/Contents/Home/jre/lib/libsplashscreen.dylib

The relevant logic in the source is:

diff --git a/src/main/c/splash.c b/src/main/c/splash.c
index 3e7d587..427dc9e 100644
--- a/src/main/c/splash.c
+++ b/src/main/c/splash.c
@@ -51,8 +51,12 @@ struct string *get_splashscreen_lib_path(const char *jre_home)
        struct string *search_root = string_initf("/System/Library/Java/JavaVirtualMachines");
        struct string *result = string_init(32);
        if (!find_file(search_root, 4, "libsplashscreen.jnilib", result)) {
-               string_release(result);
-               result = NULL;
+               string_release(search_root);
+               search_root = string_initf("/Library/Java/JavaVirtualMachines");
+               if (!find_file(search_root, 4, "libsplashscreen.dylib", result)) {
+                       string_release(result);
+                       result = NULL;
+               }
        }
        string_release(search_root);
        return result;

Although of course, the patch above is still woefully insufficient.

We want to evaluate whether it's possible to have a pure Java launcher.

The native portion would be some stock launcher such as the JavaFX launcher (see #33), or the newer experimental jpackage tool.

Probably, once Java starts up, it would need to find a suitable JDK on the system to use for actually launching the main application, and "spawn Java from Java." This gives us the power to do things like:

• Launch Python which then spins up a JVM—so that CPython stuff can be used from ImageJ.
• Reconfigure the JVM's memory settings, garbage collector flags, etc., really any custom JVM-level flag can be given on the CLI and it will be propagated to the secondarily spawned Java.
• XInitThreads library needs loading very early in the application lifecycle (see #64)—probably before any AWT classes are loaded? It might work to hard-code this into the Java-side launcher code even before the splash screen (see next paragraph) is shown. But testing needed.

Regarding splash screens: the current launcher code here now uses a pure-Java splash mechanism with minimal class loading, which is fast enough and also cross platform.

If no embedded java is present, and JAVA_HOME is unset, I'm seeing:

$ Contents/MacOS/ImageJ-macosx
No known JRE; cannot link to Java library
Warning: falling back to System JVM

Even though I have a few system-wide Java installations:

$ /usr/libexec/java_home -V
Matching Java Virtual Machines (3):
    14.0.2, x86_64:	"AdoptOpenJDK 14"	/Library/Java/JavaVirtualMachines/adoptopenjdk-14.jdk/Contents/Home
    11.0.2, x86_64:	"AdoptOpenJDK 11"	/Library/Java/JavaVirtualMachines/adoptopenjdk-11.jdk/Contents/Home
    1.8.0_265, x86_64:	"AdoptOpenJDK 8"	/Library/Java/JavaVirtualMachines/adoptopenjdk-8.jdk/Contents/Home

/Library/Java/JavaVirtualMachines/adoptopenjdk-14.jdk/Contents/Home

When running --update update I'm asked how to proceed with any jars that need to be updated. The options are in the form of 1, 2 etc...

But if I enter a selected option, it fails and kicks me back to a pseudo command prompt, although Fiji is actually still running (and I have to use ctrl + c to kill it and get back to my actual command prompt).

See attached:

From a thread on the ImageJ mailing list:

Usually, I am starting Fiji with fiji-win64 launcher and that produces the error with 3D Viewer. I have tried the launcher you have mentioned - and after rather long start 3D Viewer did not through the error. Then I moved back to the stable version of ImagJ-win64 launcher (from March 2017) and it worked as well even faster than unstable version. So, I think the culprit is somehow connected with fiji-win64 launcher not imageJ-win64 launcher.

We want to have a single unified launcher per platform. The splash screen can show the Fiji logo in the corner of the splash screen so that people know it's still Fiji. Let's stop rewriting the icon. As for the title bar, perhaps we should add the major extension bundles like Fiji to the title bar in a more orderly way (e.g., if you have Fiji and BoneJ installed, it could say something like "ImageJ +Fiji +BoneJ"). Topic for discussion at the December hackathon.

See also #44, #53, #54.

@ctrueden reported that --ij2 --run <name> does not work right now.

The Launcher provides a --run command to launch plugins directly from the command line. But it seems it stopped working after the 2014 Jun update to ImageJ2.

Even if Java 7 or 8 is installed, and even if that version is requested via the --java-home flag and/or JAVA_HOME environment variable, the ImageJ launcher still prompts to install Java 6. If possible, we should avoid doing that.

Maybe this is caused by the executable linking to the Java 6 shared library? If so, we might need to do some more shenanigans with multiple executables a la ImageJ-macosx and ImageJ-tiger, to avoid invoking a tainted executable unless Java 6 is actually needed...

In Mac OS X Mavericks, the Finder no longer passes the "-psn_" flag to applications. In ImageJ.c line 1613, the launcher checks for the -psn_ flag to determine if it should chdir into ij_dir or not. Since the flag is no longer passed, it never happens. I think the chdir should happen regardless of whether the app was run from the Finder or not, so just moving the chdir on line 1624 outside of the if statement should work.

We might want to pass -Duser.language=EN to java always. See this fiji-devel thread for details.

@PaulVanSchayck writes:

Yes, fiji does show the --js option. However ImageJ2 does not. And while I (now!) understand the technical reasons why the -macro option is not mentioned it makes for a very confusing user experience. Right now, for someone new to IJ it's very difficult to understand the relation between IJ1 and IJ2. The help of the commands not being complete adds to that.

We should document all the options supported by ImageJ itself on the Java side, not just those supported by the launcher itself. It is the ImageJ launcher, after all.

Since ImageJ2 makes these options extensible, one possibility would be for the launcher to invoke net.imagej.Main with --help when it is given --help, so that ImageJ itself can report its own help instructions in addition to those of the launcher.

@PaulVanSchayck pointed out that the Javascript support only works in Fiji.app/, not in ImageJ.app/. The best fix is to let the scripting framework handle things.

So if we detect that the first argument is a path to an existing file with a non-empty file extension, we should spin up a Context and ask the ScriptService whether it knows about the file extension, and let it handle the execution if it does.

This does not fix ImageJ-<platform> --js -- which is supposed to open an interactive console -- of course, but that is something we might have to address in the ScriptService instead (or in a to-be-introduced ScriptInterpreterService).

At least on Windows 10 (haven't tested other versions) the following call will not return even if the Jython script exits:

$ .\ImageJ-win64.exe --ij2 --headless --console --run someScript.py

The problem can be remedied by using java.exe instead of javaw.exe in the aforementioned configuration. That is, I would expect the ImageJ process to exit when a script that I execute with --headless --run exits.

See also:

• http://forum.imagej.net/t/need-help-with-exiting-python-script/7832/8

We will now use Travis and AppVeyor to build and deploy the platform-specific native binaries. The bare executables will be deployed using deploy:deploy-file rather than deploying the wrapped NARs.

So we don't really need the .nar files anymore. And we'd really like the main imagej-launcher-x.y.z.nar to actually be named imagej-launcher-x.y.z.jar in the repository, and for Maven to treat it like a normal JAR file instead of a black box packaging type.

We can eliminate use of the NAR plugin completely by migrating the build instructions out of the NAR plugin's configuration in the pom.xml in favor of having individual platform-specific build scripts. This gives us very fine-grained control over exactly how the launcher is built on each platform, as opposed to using CMake, which would be theoretically nice but maybe (in my experience trying it with this specific project) more time-consuming to get right.

Maven-wise, this project would then be structured as a normal pure-Java project, with the native code being built in a separate step by the CI platforms.

See http://forum.imagej.net/t/please-test-the-new-imagej-launcher/8238/8.

The launcher has special logic on OSX for how it starts up ImageJ.

It's possible all that we need to do is update how the set_path_to_apple_JVM method works? But it could also be something in the start_ij_macosx method.

If necessary we may need to restructure the macosx Java-8 bundle as well.

Reported by @sinverso
When compiling from the command line, e.g. via: fiji --javac *.java the annotations are written out as files matching the annotation name, whose contents are the classes with that annotation.

However, no META-INF directory is produced, and these files do not actually allow the annotations to be detected even if they are on the classpath, e.g. via fiji -cp . Main.class

On the other hand, if the compilation step specifies an ouptut directory, even if it's the current working directory, e.g. fiji --javac -d . *.java, a META-INF is created and functions properly when calling a main class as above.

See https://list.nih.gov/cgi-bin/wa.exe?A2=IMAGEJ;217b820.1503

The new Java splash screen (#53) supports a progress bar that is currently static.

For example:

ImageJ --debugger --update list-modified

Results in a random port being chosen for remote debugging, but then the main ImageJ application window appears rather than executing the intended command-line Updater action.

Whereas this invocation works as desired:

ImageJ --debugger= --update list-modified

Relatedly:

ImageJ --debugger=suspend --update list-modified

Does not respect the suspend, but does execute the updater action.

Noticed by @joshmoore.

On OSX, using an ImageJ.cfg in ImageJ.app/, with the line:
maxheap.mb = 384

the max memory is still being set to 3/4 available RAM. So this configuration file is not being properly respected by the launcher.

Migrated-From: http://trac.imagej.net/ticket/2034

Launching Fiji with Java 8 gives the following javassist failures:

• Cannot handle replace call to list in ij.Menus's public static synchronized java.lang.String[] getPlugins()
• Cannot handle app name in ij.ImageJ's public <init>(java.applet.Applet applet, int mode)

Both seem to stem from a common:
java.io.IOException: invalid constant type: 18 at 168

Currently if a home made jython script/macro is saved as a plugin and executed, it runs fine but the following error message is still displayed :

console: Failed to install '': java.nio.charset.UnsupportedCharsetException: cp0.

It can be fixed by adding the following argument to the ImageJ.cfg (after Xmx****m for instance) or to the command line (for headless mode)
-Dpython.console.encoding=UTF-8

It would be nice to have it as a default.

This is reported on the forum here and there

From @rasband:

Another problem with the launcher on OS X is that I have not found a way to get it to use an embedded JRE. I tried putting a Java 8 JRE in Image.app/jre but the launcher did not use it.

If you launch ImageJ with the --debug flag, you can see that it is detecting the JRE, but still ultimately does not use it:

$ cd /Applications/Science/ImageJ.app
$ cp -rp /Library/Java/JavaVirtualMachines/jdk1.8.0_11.jdk/Contents/Home/jre .
$ Contents/MacOS/ImageJ-macosx --debug
Available RAM: 4919MB, using 3/4 of that: 3690MB
JRE found in '/Applications/Science/ImageJ.app/jre'
Re-executing with correct library lookup path (/Applications/Science/ImageJ.app/lib/macosx:/Applications/Science/ImageJ.app/mm/macosx)
Available RAM: 4919MB, using 3/4 of that: 3690MB
JRE found in '/Applications/Science/ImageJ.app/jre'
java -Djava.ext.dirs=/Applications/Science/ImageJ.app/java/macosx-java3d/Home/lib/ext/Library/Java/Extensions:/System/Library/Java/Extensions:/System/Library/Frameworks/JavaVM.framework/Home/lib/ext -Dpython.cachedir.skip=true -Dplugins.dir=/Applications/Science/ImageJ.app -Xmx3690m -Xincgc -XX:PermSize=128m -Djava.class.path=/Applications/Science/ImageJ.app/jars/imagej-launcher-3.1.6.jar -Dimagej.dir=/Applications/Science/ImageJ.app -Dij.dir=/Applications/Science/ImageJ.app -Dfiji.dir=/Applications/Science/ImageJ.app -Dfiji.defaultLibPath=lib/server/libjvm.dylib -Dfiji.executable=/Applications/Science/ImageJ.app/Contents/MacOS/ImageJ-macosx -Dij.executable=/Applications/Science/ImageJ.app/Contents/MacOS/ImageJ-macosx -Djava.library.path=/Applications/Science/ImageJ.app/lib/macosx:/Applications/Science/ImageJ.app/mm/macosx -Dij.debug=true -Dscijava.log.level=debug net.imagej.launcher.ClassLauncher -ijjarpath jars -ijjarpath plugins net.imagej.Main
JavaVMBundlerVersionsDirURL: /System/Library/Frameworks/JavaVM.framework/Versions
TargetJavaVM: /System/Library/Frameworks/JavaVM.framework/Versions/1.6
Setting JAVA_JVM_VERSION to 1.6

In the interest of pragmatism, here is a list of issues I want to ensure are fixed before we distribute a new native launcher to all ImageJ users:

• The splash screen might not show up on Ubuntu 18.04. Testing needed.
• Could not find X11 library, not running XInitThreads on Ubuntu 18.04. Track down why.
• ignoring option PermSize=128m; support was removed in 8.0 No reason to keep this flag in the launcher anymore.
• Using incremental CMS is deprecated and will likely be removed in a future release No reason to keep this flag in the launcher anymore.
• Consider reverting #57 in favor of setting it on the Java side during startup.

CC @LauLauThom @stelfrich

As reported by @imagejan in #57 (comment), there seems to be an issue with the launcher when it's used with Java 10 (and/or very likely also with Java 11) on Windows.

@imagejan: Could you please clarify if you encounter the issue with an OpenJDK or Oracle JDK?

If I run ImageJ-win64.exe --update update to update Fiji from the command line, it just does nothing with no output right now.

If I run ImageJ-win64.exe --debug --update update, it works! and now finds the things to update, and asks what I'd like to do with them..

There was a report that updating to the latest (6.0.1) launcher on Windows 10 resulted in a new request for firewall access from javaw.exe, whereas in the past the access was via ImageJ-win64.exe.

Looking through my personal firewall records I found entries for both ImageJ-win64.exe and various Java runtimes.

So it seems that each Java version requires its own access, and if a Java version used with an old launcher had already been excepted, we would need to confirm that this actually is due to the launcher and not changing Java versions.

Locally, I when testing with ImageJ 1.x with an ImageJ.cfg, I get a firewall request for the JRE pointed to in the ImageJ.cfg.

I have not been able trigger a firewall request from either ImageJ-win64.exe or its bundled Java.

I also noticed that some ImageJ plugins may have their own firewall hits (3D viewer?).

So I would like to understand:

• When exactly are these firewall hits made?
• Can they be run through a common process so that changes to the Java version, launcher, or plugins do not trigger new Firewall hits?

Our goal is to simplify the ImageJ launch process so we are not so intimately tied to a custom, complex launcher with its own JDK version concerns.

Perfect world goals include:

• We bundle latest Java with all the JRE-included bundles
• ImageJ options have a way for users to point to their JRE of choice
• Users are free to still use older Java versions (i.e. 6) with an OS-agnostic no-JRE bundle
• we can easily distribute ImageJ, without requiring the Fiji update site

JavaFX is currently our first choice for deployment. It appears to be capable of building standalone (no bundled JRE) and self-contained (bundled JRE) apps cross-platform. These is also a maven plugin

JavaFX issues that need to be solved:

• Not able to set <fx:platform basedir=""/> to get standalone deployment. SOLVED by using build.xml. See also javafx-maven-plugin/javafx-maven-plugin#127.
• jfx:native goal doesn't respect app name configuration. SOLVED - see javafx-maven-plugin/javafx-maven-plugin#128.
• Preloaders. WONTUSE preloaders live in the same JVM as the application. They will not meet our needs.
• Command line arguments - we need to be able to support things like --debugger=8000 which the native launcher translated to JVM argument(s). See SO #30809330.
• Figure out how we want to handle updating. This is tied to the refresh menus problem. It sounds like the .jar lock in Windows may be fixed in Java 7 allowing runtime swapping, in which case checking for updates at startup and replacing .jars before loading classes and spinning up a context may be an option worth investigating, especially if we remove the ImageJ update site - which would become an immutable /lib.
• We need a splash screen. Options would be using java -splash or JavaFX.
• To test: what happens if you try running a no-JRE JFX distribution on a platform without Java installed?

Platform-specific notes

Linux

• Debian bundler requires fakeroot to be installed and just fails if it isn't. This will only affect developer machines though.
• Native launcher produced by debian bundler fails with no packaged JRE (message complains that JRE can't be found)

Windows

• Install WiX (wixtoolset.org) - Version 3.X
• Install Inno Setup jrsoftware.org/isdl.php
• Had to fix classpath (didn't have to on linux/osx)
• exe installer installed to C:\Users\username\AppData\Local\ImageJ
• msi installer installed to C:\Program Files\ImageJ
• icon works except it's lost on the app for .exe installer