allow setting install prefix for jdks, create junction point / symlink for multiple LTS versions

[maxfieb]

Is your feature request related to a problem? Please describe.

Whenever a jdk is updated, it breaks the path for those apps that need a particular LTS version. If you have general apps JAVA_HOME set for jdk 11 LTS which seems to work for most things. But then when you want more modern LTS 17 for things ( even very old things that use JDK 8) that want to support a particular LTS the path breaks.

Also, the updater always defaults to the msi installer's notion of a default location, usually somewhere on C: which if you have a PC or laptop with C: SSD smaller disk and D: larger spinning disk, it's usually a battle to keep C: less full, as Windows OS and Programs insist on using C: ( Windows Docker Desktop ) to install.

Also OCD people might like everything in D:\Java\ or some such convention.

I'm sure that it's not a 'known-not-a-bug'
[X] Yes

Describe the solution you'd like

It'd be nice to specify a filesystem prefix where new jdks are installed by update watcher, when the msi's are run you could specify the prefix for the installer, and default to prefix baked into the .msi installer if there was no default prefix.

Also it'd be nice if it could create a junction point / symbolic link for each major/LTS version. This used to be a feature in the old oracle installer ( but it ignored LTS's only did one version ) to make a junction point, and handle the modern multi LTS world and not just one latest version. There is another LTS coming soon, at the end of the year. Already I can see use case for java only supporting 8 or 11, while the most recent version is 17. The release LTS 21 might make some things only supporting 17 ?

If javas installed in default prefix D:\Java, say there is D:\Java\jdk-17.0.8.7-hotspot a windows junction point could be created ( D:\Java\jdk-17 -> D:\Java\jdk-17.0.8.7-hotspot ) and programs than wanted LTS 17 specifically, rather than the default version in JAVA_HOME it could point at D:\Java\jdk-17, then not break when the java updates ( the update watcher would create/update the junction point when installing a new version )

Describe alternatives you've considered

A simple option might be to set a custom java home, eg LEGACY_JAVA_HOME for jdk versions 8 (instead of JAVA_HOME for eg. the jdk8* versions)for compiling older code or test cases, and the usual JAVA_HOME for most things.

But that would be less ideal, as there is less opportunity to use custom java home, it would require developer or shell script etc., prior to app running and most people who are app users may not be able to do this, and JAVA_HOME is universally supported for most apps.

Additional context
Add any other context or screenshots about the feature request here.

[tushev]

Hello, thank you for your suggestions.

As I see it, you're asking about two features:

1. The first one is a consistency in installation paths. Currently there are two types of Java installations here: auto-discovered and manually-managed ones. I can add an option to keep the installation directory unchanged for manually-managed ones. So, if you have Javas in D:\Java\JRE11 and D:\Java\JDK17 you would simply convert them to manually-managed ones, and set a flag to keep the install dir.

I will implement it in one of the future releases.

2. As for automatic management of symlinks+, it's an extremely messy-and-hard-to-implement solution - because there are no existing standards. Instead, I propose that advanced users create their own solution (that will fit their workflow) using these already implemented features:

• https://github.com/tushev/aojdk-updatewatcher/wiki/%E2%9A%A0-Advanced-configuration#set-up-sample-post-install-script-to-run-after-updates-are-installed
• https://github.com/tushev/aojdk-updatewatcher/wiki/Sample-postinstall-scripts

[hueldoeu]

AWESOME APP!!!

[hueldoeu]

If you find this app useful, stars are appreciated :) GitHub stars

how can i give you a star?