New ImageJ launcher overwrites JAVA_HOME with JRE

Hi @hinerm,

I’m observing a strange bug with the new ImageJ-launcher. When calling maven from Fiji, Fiji with the new launcher outputs this error:

Run maven...
The JAVA_HOME environment variable is not defined correctly 
This environment variable is needed to run this program 
NB: JAVA_HOME should point to a JDK not a JRE 

While Fiji with the old launcher runs through…

[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time:  5.956 s
[INFO] Finished at: 2020-11-09T13:22:40+01:00
[INFO] ------------------------------------------------------------------------

I call maven using SciJavas ProcessUtils:

With these parameters:

I know, I may be the only crazy guy calling maven from Fiji. But I distribute this to people. Thus, if you have any idea how to fix this (potentially on my side) I’d be happy to hear any hint!

Thanks!

Cheers,
Robert

Addendum: That’s my enviroment variables:
image

@haesleinhuepf when using a bundled Java, the launcher sets JAVA_HOME to point to it. I suspect this is to ensure environments that do not have an independently installed/configured Java will have a working JAVA_HOME.

There are probably many ways to check what JAVA_HOME is in your Fiji, but a simple way is in the script editor:

You can see that I have a Corretto JDK as my system JAVA_HOME but it’s being overridden in Fiji with the bundled JRE.

Anyway, the solution to your problem (I hope) is to launch Fiji with a JDK - by either replacing or removing the bundled Java.

Hey Mark,

I executed this little script you suggested with both launchers and it outputs the same: The JDK inside Fijis java folder.

However, while the maven call works from the old launcher:

I still get the error with the new launcher:

First of all, I don’t know how to do this. Second of all do you think, I should tell all my collaborators how to do this?

Btw. if you’re curious, the procedure I’m doing is explained here:

To be honest, the only difference is the imagej.exe I’m starting up. The bug is in the launcher. Can this bug be fixed in the launcher?

Thanks again!

Cheers,
Robert

@haesleinhuepf the FAQ has an entry on it.

The order of Java preferences is:

  1. ImageJ.cfg (but scheduled for obsolescence so please don’t use this mechanism)
  2. Fiji.app/java/[platform]
  3. JAVA_HOME
  4. System Java (e.g. registry entries on Windows)

So you could either:

  • Delete/move/rename Fiji.app/java. The launcher should then use the Java at JAVA_HOME
  • Copy your jdk at C:\Program Files\Java\jdk1.8.0_202 to Fiji.app/java/win64 and remove the 1.8.0_172

Can you test one/both of those with the new launcher and see if the Maven call works?

Assuming this is failing only because the launcher is using a bundled Java, which happens to be a JRE, I would call it a change in behavior but not a bug.

Your Maven command works from within ImageJ with the old launcher because you had a separately installed JDK and had independently set JAVA_HOME. The new launcher gives ImageJ a chance to work with Maven out of the box without the user having to set environment variables (if that ImageJ came with a bundled JDK).

In my opinion the big-picture problem here is that Fiji has propagated bundled versions of Java without a mechanism for controlling/updating that Java.

Yes, but I would say the same thing to someone writing plugins requiring, for example, JavaFX. If a library requires a feature of Java not included in the bundled Java, some level of workaround may be required.

Absolutely I do not want this to have to be done manually. There should be a system for declaring requirements like this (a JDK, JavaFX, Java 9, etc…). But we aren’t there right now.

Ok, I obviously cannot delete the java folder on my collaborators computers. And again, my JAVA_HOME config is correctly set. I think I will distribute the old launcher with my update site. I’m sorry but I just don’t have time to fix this.

@haesleinhuepf regardless of which launcher used, your collaborators have to do something to use Maven from Fiji, because all the bundles before last week included either no Java, or a JRE.

Your installation instructions indicate the user has to install a JDK. To be compatible with the new launcher, currently, users have to go one step further to ensure their Fiji is actually using that JDK to launch.

Correctly set for your system, yes. But Fiji/ImageJ is a self-contained Java application. With the goal of reproducibility, the ability to override system configuration in favor of a bundled Java is essential.

With the new launcher, placing a Java in Fiji.app/java is no different than using an ImageJ.cfg (or eclipse.ini) to control the Java being used in the application. This has always been true, but the new launcher is stricter by preventing an environment that mixes multiple versions of Java.

If a user wants to use the convention of JAVA_HOME, they still can, but any overriding configuration has to be removed (by deleting/renaming Fiji.app/java).

If they want to guarantee consistent operation within Fiji, then they should put a JDK in Fiji.app/java/[platform]

For what it’s worth I tested the new launcher with a JDK and confirmed that it was able to run the Generate CLIJx / Fiji plugins command. It failed to gather dependencies, but didn’t have a problem executing Maven. (and I confirmed that running with a JRE failed to start maven, as you saw)

1 Like

How did you make it work? Copying the JDK into Fijis folder? Thanks for your support!

1 Like

Yes exactly:

I’m so sorry for the interruption! I really appreciate all your testing and feedback.

Hi, All of my updates are failing with the following msgs. I can’t seem to use the BAR plugin that I love so much. I believe that this is happening since I updated to the latest Java version :

java.io.FileNotFoundException: C:\PROGRA~1\Fiji.app\db.xml.gz.tmp (Access is denied)
	at java.io.FileOutputStream.open0(Native Method)
	at java.io.FileOutputStream.open(FileOutputStream.java:270)
	at java.io.FileOutputStream.<init>(FileOutputStream.java:213)
	at java.io.FileOutputStream.<init>(FileOutputStream.java:162)
	at net.imagej.updater.FilesCollection.write(FilesCollection.java:443)
	at net.imagej.updater.util.AvailableSites.applySitesURLUpdates(AvailableSites.java:299)
	at net.imagej.ui.swing.updater.ImageJUpdater.refreshUpdateSites(ImageJUpdater.java:264)
	at net.imagej.ui.swing.updater.ImageJUpdater.run(ImageJUpdater.java:144)
	at org.scijava.command.CommandModule.run(CommandModule.java:196)
	at org.scijava.module.ModuleRunner.run(ModuleRunner.java:165)
	at org.scijava.module.ModuleRunner.call(ModuleRunner.java:124)
	at org.scijava.module.ModuleRunner.call(ModuleRunner.java:63)
	at org.scijava.thread.DefaultThreadService.lambda$wrap$2(DefaultThreadService.java:225)
	at java.util.concurrent.FutureTask.run(FutureTask.java:266)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
	at java.lang.Thread.run(Thread.java:748)

Hey @Vaibhav_Tale,

please don’t install Fiji in the C:/program files/ directory, because Fiji needs write-access to intall updates. Install it in a different folder where you do have write-access. Also see the note on the website.

Let us know if this helps!

Cheers,
Robert

1 Like

Hi Robert,
Thank you so much! It fixed my issue. Strangely had been using it for a year and never had any issues. I think our IT just updated our security systems and I believe that they must have added a few more restrictions.

1 Like