Would like an installer option that would preserve previous installs

[BillPhillips]

It would be nice for a version 8 installer option that would preserve previous version installs.

This is useful for support activities and build servers where older versions of the JDK need to be supported.

We picked up AdoptOpenJDK back around the ~200 build precisely because it did not interfere with previous installs and the JDKs could be referenced purely via JAVA_HOME.

[aahlenst]

What platform are you referring to?

[BillPhillips]

Windows installer.

Is that what you’re asking?

Bill

Sent from my iPhone

On Jul 22, 2020, at 4:11 PM, Andreas Ahlenstorf [email protected] wrote:

What platform are you referring to?

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or unsubscribe.

[aahlenst]

Removing the previous version of the same major version is a feature and the majority of the users is not supposed to use outdated versions. If you're happy to swap versions by changing JAVA_HOME, why don't you use the ZIP? That's what I use in similar circumstances. If that does not fit your bill, tell me more about your use case.

[nmatt]

I just ran into a similar problem. Having 8u252 installed, I installed the current 8u272 nightly build, unaware that this would remove the 8u252. In fact it only partially removed it, because the files were in use by my IDE. I only noticed the issue after the IDE started to behave strangly. To again have a release build, I then decided to install 8u265 using the MSI, which refused the installation because a newer version is already installed (the nightly). Now I have to uninstall the nightly, install the 8u265 using the MSI (to get the registry settings etc.), and then reinstall the nightly but using the ZIP. All of this is surprising, and different from how the Oracle installers behaved.

I would argue that:

1. Installers should warn that they replace the existing (older) version.
2. Provide an option to retain the existing installation instead of (a) replacing an installed older version or (b) refusing to install when the installed version is newer.

[aahlenst]

@nmatt Your use case (sounds like testing of nightly builds) requires configuration capabilities post installation whereas MSI installers (by design) offer only configurability at installation time. If we retained the old version, you could not use it anyway without manually reconfiguring the system. So you gained nothing but made life miserable for 95% of the other users.

You need a version manager. I want to create something like that because I have the exact same problem (my computer is full of JDK versions for testing purposes). But I haven't found any volunteers so far.

[aahlenst]

That nugget is interesting, however:

(...) and different from how the Oracle installers behaved.

Can you please elaborate on that? I only remember the auto-updater that nagged me about updating to the next patch level release by overwriting what's already there.

[nmatt]

@aahlenst: The Oracle installer didn't remove existing JDK installations, and you could choose whether or not to install the public JRE in addition to the JDK. The public JRE was the only thing that did any "overwriting" (= replacing what to use as the default JRE). If you de-selected the "public JRE" option, the JDK was simply installed in the specified directory, not much different from unpacking the zip I guess. The auto-updater could be easily deactivated, and wasn't reactivated when using the JDK installer instead of the JRE-only installer from java.com (if I remember correctly).

One reason to prefer the installer is for all installed JDKs to be listed in Window's installed programs list, and to have the uninstall option there for each one. Personally I also find it easier to always just select the installer and merely choose different options in the installer GUI based on use-case, rather than having to think beforehand about whether the MSI can work for my use-case or not.

I'm not sure what you mean by post-installation configuration capabilities. The only thing I need to configure to use any given non-default JDK is the directory (JAVA_HOME or equivalent).