Make the updater understand multiple update site tracks

[ctrueden]

Different artifacts need to be served depending on:

1. Major version of Java
2. Stable versus unstable component versions

Major version of Java

For example, instead of https://update.imagej.net/ being the sole core ImageJ2 update site, there needs to be:

• https://update.imagej.net/6/
• https://update.imagej.net/8/
• https://update.imagej.net/11/
• https://update.imagej.net/17/

For each supported major version of OpenJDK. And the updater automatically uses the best one based on the installed version of Java.

This is complicated by JavaFX, because:

• Java 6 does not support JavaFX
• Java 8 has bundled JavaFX 8
• Java 11+ has split JavaFX to its own project OpenJFX which you depend on like any other library (whew!)

And unfortunately, the JavaFX API broke between JavaFX8 and JavaFX11.

Therefore, for plugins like mars-fx and flimj-fx currently built on JavaFX 8, we need to take care not to break them when designing this multi-track update site mechanism.

How the Updater needs to change

The Updater needs to:

• Check the version of Java, and append /<major-version> to the update site appropriately.
• Deal with the case where that particular URL prefix does not exist remotely.
  • Repeatedly fall back to prior versions? E.g. if /11 does not exist, try /10, /9, /8, /7, /6, ...?
    • Should we include support for non-LTS versions of Java in this way? People will probably want it.
    • Maybe use a java-versions manifest file in the root of the multi-site declaring which versions of Java have tracks?
    • We could parse the directory listing but that's error prone for people who don't use Apache or don't enable indexing on their sites. Let's not.
  • Or: symlink as appropriate on the server side, so that the updater never needs to fall back?
• Be careful about existing update site content! It will probably need to remain in place forever, unfortunately.
  • Old versions of the Updater cannot follow 301 redirects—but try testing that again just to be sure.
  • For update.imagej.net, update.fiji.net, sites.imagej.net, we could maybe use hard links to duplicate the files without extra disk usage?
• Give the user an informative dialog box when it detects that an update site has a newer major Java version track than it can follow, due to the locally installed version of Java being too old.

Important question: How to handle major-version-sensitive content like JavaFX plugins?

• Most plugins can run under a version of Java newer than what they target. E.g. a Java-8-based plugin can run with Java 11.
• But JavaFX8-based plugins won't work with JavaFX11. This is a special case; now that JavaFX11 is external, it should work e.g. with Java 17.
• Other examples of major-version sensitivity: java preview and experimental features. These are new features of a particular OpenJDK major version, which are subject to change in future and won't be supported in later major versions. So if a plugin wants to use them, they need to stay in one particular update site track.

Stable versus unstable

To support stable versus unstable tracks, we can lean on Maven (#104). With such a design, every update site built on a Maven artifact would automatically have stable vs unstable tracks. But how to teach the Updater to understand this? And how to name them on the remote?

• /8-stable, /8-unstable, /11-stable, /11-unstable?
• Nested directories?
• stable/unstable versus release/snapshot?
• All of these are ugly and complexify things...

[ctrueden]

This forum discussion touches on issues relevant to this work.