Add mechanism for updating Java #93
Conversation
hinerm
commented
May 14, 2024
•
hinerm
commented
hinerm
force-pushed
the
download-java
branch
2 times, most recently
from
2ee0eda
to
d9c0a1a
Compare
We can now control the java version per-platform using https://downloads.imagej.net/java/jdk-urls.txt, which contains URLs for JDK downloads. These are cached locally and any time a more-recent version is available, it is downloaded to the appropriate /java sub-directory. If jaunch is being used, an app.cfg file is created to tell the launcher which JDK to use on subsequent launches.
|
This logic should be moved to Jaunch or ClassLauncher instead |
|
Improvement to the logic is needed in that we're only really considering managed versions of Java right now.
|
There are lots of ways users can run Fiji with a different OpenJDK 21 than the one we download and unpack, without having set up Jaunch manually. Assuming the user has installed SciJava Ops by enabling the SciJava Ops update site etc., they could then:
|
|
When comparing java versions we need to know if the current Java is a bundled Java or custom. We can use the FileDownloader logic for actually doing the downloads. For the update checking comparison timing, instead of doing it pre-emptively, we can do it when the application fails to launch because of Java versions. But we probably still want a mechanism tied to the updater, which could mean adding a dependency on imagej-launcher. Ideally this update-time check would be migrated to the ImageJ-Updater component |
|
Other consideration: how can we get the Java updating to work with the command line updater? In the launcher we could have a boolean For the command line updater, could we easily add an |
