Update Java version

[frauzufall]

It would be nice to update the Java version via the updater. We have discussed this in the past and said that this is not a priority right now, but having an issue will help keep track of it. Please tell me if this discussion already takes place in a different issue.

Here are some reasons:

Updates are provided by update sites and Java is not on an update site.

Shipping Java is highly platform dependent.

Updates from the update sites first get downloaded to Fiji.app/update/ before they are moved into the right spot during the next Fiji launch because one cannot hot swap the components while they are loaded, at least not on all systems. Not sure if the launcher can do this with Java as well.

[hinerm]

This plan was stymied a bit by the existing ImageJ native launcher's ability to recognize newer versions of Java. With Jaunch we now have a viable alternative native launcher and can/must proceed with updating the Java version in Fiji. There are several stages to this plan:

Teach the updater to update Java

• Create a simple utility in e.g. scijava-common for writing key:value pairs in plain text, i.e. File -> Map<String, String> and Map<String, String> -> File methods. Relevant PR: Add text-based property util scijava/scijava-common#477
• Create a text file in downloads.imagej.net/java that contains download links to the latest JVM for each platform. Taken from here.
• Modify the ImageJ updater so that, before looking at its updatable files, it:
  • Checks if network and HTTPS is available, failing if not
  • Downloads the java links file. If it doesn't have a local copy, or the cached copy is different than the new version, then a Java update is available.
• If a Java update is available, we UIService.showDialog and ask the user if they would like to update, noting that a new Java version may take a bit to download but will be required for updates beyond a certain point.
  • If they reject, proceed to normal updates
• If the update is accepted, we:
  • Show a new progress dialog as we asynchronously download the Java version appropriate for their system to a temp directory marked deleteOnExit. (can the DownloadService handle this?)
  • When complete, extract the download to their appropriate java app subdir
  • Use our k:v utility to write out a fiji.cfg that will be used by jaunch. This will store the java version, as well as user options like Edit > Options > Memory and threads.
  • Once we are sure that the Java update is complete, continue on with the normal update
  • Relevant PR: Add mechanism for updating Java imagej-ui-swing#93
• Add support for Jaunch in imagej-updater
  • Relevant PR: Add support for updating Jaunch files #110
• To be done by the updater?
  • Turn on our new "Java 21" update site
  • Turn off Java 8 Fiji/ImageJ sites
  • Critically: we must ensure (e.g. programmatically) that the new launch that happens after this point is with jaunch. If the wrong launcher is used, user needs to be notified.

Note of other related files: CheckForUpdates, PromptUserToUpdate

Update site changes

On the existing ImageJ/Fiji Java 8 sites:

• Ship the dead-ending updater
• Also include the base Jaunch files to avoid the potential for the updater updating itself but not receiving the new Jaunch launcher, resulting in inoperable state
  • This means the updater will need to recognize the jaunch directory

On the new Java 21 update site:

• New info.plist
• New .desktop

imagej-updater changes

• May need to remove scijava-common dependency (and any others?) and keep this purely Java 8 to facilitate longevity of existing installations

Recovering from installation problems

Download the latest Fiji and unpack it on top of the existing installation, to just add new files.

Expand db.xml.gz to include minimum java version

[ctrueden]

With 71117ab, the Updater now recognizes the folder config. One of Jaunch's supported configuration folders is config/jaunch, so we can push the Jaunch config up to that folder now.

[ctrueden]

I started looking at what it will take to make the new Jaunch executables supported by the Updater. It's pretty messy. Here is the first patch I started:

diff --git a/src/main/java/net/imagej/updater/util/UpdaterUtil.java b/src/main/java/net/imagej/updater/util/UpdaterUtil.java
index 5d34d82..baa616f 100644
--- a/src/main/java/net/imagej/updater/util/UpdaterUtil.java
+++ b/src/main/java/net/imagej/updater/util/UpdaterUtil.java
@@ -109,11 +109,23 @@ public class UpdaterUtil {
 		final int macIndex = 2;
 		Arrays.sort(platforms);
 
-		launchers = platforms.clone();
-		for (int i = 0; i < launchers.length; i++)
-			launchers[i] =
-				(i == macIndex || i == macIndex + 1 ? macPrefix : "") + "ImageJ-" +
-					platforms[i] + (platforms[i].startsWith("win") ? ".exe" : "");
+		launchers = new String[] {
+			// Jaunch: https://github.com/apposed/jaunch
+			"fiji-linux-arm64",
+			"fiji-linux-x64",
+			"Contents/Home/fiji-macos-arm64",
+			"Contents/Home/fiji-macos-universal",
+			"Contents/Home/fiji-macos-x64",
+			"fiji-windows-x64.exe",
+			"fiji.py",
+			// ImageJ Launcher: https://github.com/imagej/imagej-launcher
+			"ImageJ-linux32",
+			"ImageJ-linux64",
+			"Contents/MacOS/ImageJ-macosx",
+			"Contents/MacOS/ImageJ-tiger",
+			"ImageJ-win32.exe",
+			"ImageJ-win64.exe"
+		};
 		Arrays.sort(launchers);
 
 		updateablePlatforms = new HashSet<>();

But there is more that will need to be done. We should update the platforms beyond the current list (win32, win64, macosx, linux32, linux64), which is too restrictive/ambiguous, now that we have macOS arm64 and Linux arm64 and potentially windows-arm64 in the future. This will need to be done carefully and tested well.

[ctrueden]

@hinerm Regarding where to download the new OpenJDK version from: upon reflection, I think using cdn.azul.com is a good idea. They have a great infrastructure already and e.g. GitHub Actions uses them to bootstrap OpenJDK in the setup-java action. It will be better for folks worldwide than leaning on downloads.imagej.net which is not behind a CDN right now.