Changed INSTALLDIR to fixed path to fix #422 and #600

[adipiciu]

By using only the Major version in the installdir path, the installation directory will not change during upgrades.

C:\Program Files\Eclipse Adoptium\jre-8-hotspot
C:\Program Files\Eclipse Adoptium\jdk-8-hotspot
C:\Program Files\Eclipse Adoptium\jre-11-hotspot
etc..

[adipiciu]

Zulu, Liberica and Corretto are also using only the major version in the installdir path.

[karianna]

what happens in the upgrade use case for existing installs?

[adipiciu]

what happens in the upgrade use case for existing installs?

The same thing as before, the installdir changes to the new one with a different version. But with this change, the installdir will remain fixed in the future.

[sxa]

We discussed this at the PMC today and generally agreed with this approach, however we should consider whether jdk-xx-hotspot is the right directory name for this or if we can select something better, so I'm opening this question to interested parties as to what the correct top level directory name should be.

[sxa]

Comparing with Linux, which installs under /usr/lib/jvm and has directories named:

temurin-17-jdk-amd64 (.deb)
temurin-17-jdk (.rpm)

On that basis it feels like a format change to temurin-xx-jdk etc. for windows would be appropriate - what do others think? Noting that while the Windows builds are using hotspot our build system typically has temurin as a value for VARIANT which is explicitly distint from hotspot so this would potentially be preferable.

[adipiciu]

@sxa 'temurin-17-jdk' seems fine for me. But there is no temurin JVM variant. See #438

[adipiciu]

Actually, Eclipse Adoptium is already in the path, so temurin is redundant. Right now, as mentioned here #2671, temurin = hotspot, but this was just a workaround. You should rely on the VENDOR variable to build a vanilla JDK, not on the JVM variant...
So the 'temurin-17-jdk' option is wrong.

[sxa]

as mentioned here adoptium/temurin-build#2671, temurin = hotspot, but this was just a workaround

Yep - it was me that implemented that change - VARIANT was just the easiest differentiator in the build process as it can also be set to things like dragonwell, corretto, bisheng which are all fundamentally hotspot based, as well as openj9 which isn't.

@sxa 'temurin-17-jdk' seems fine for me. But there is no temurin JVM variant. See #438

You're right that there is no difference in the JIT (other than anything arising from the compilers we use, and the compiler options) however Eclipse Adoptium is the vendor so it's right that the top level directory has that, but Temurin is our brand of openjdk so there's a good argument to have that in the directory path too IMHO to make the name visible, especially if it gives us consistency in the naming with the Linux installers.

(Note - I'm willing to be convinced either way, but I'm probably 80% towards going for temurin in the name and I'm interested to hear everyone's opinions on it :-) )

[douph1]

What will happen to the running JVM when you delete/add/replace files/libs from same folder of existing process ?

[steelhead31]

I'm assuming this is just a default path shown in the MSI installer, and as such is still available to be overridden at install time, as its definitely useful to be able to install multiple versions of the same major release for testing/evaluating upgrades.

I think I agree with @sxa , I'd like temurin in the name too, .. the default path in the most recent JDK21 installer is

c:\program files\Eclipse Adoptium\jdk21.0.2.13-hotspot

adjusting this to be c:\program files\Eclipse Adoptium\temurin-21-jdk would bring consistency with the other platforms. Its only a default/suggestion, so I guess its always

[douph1]

I think I remember that some time ago Oracle installer ask user to close running jvm before upgrade in place.
We can't do that (because we don't know how).

Why are older Oracle installer was doing that before ? To not have a running jvm with some new files and some old files, or because some files where locked and cannot be updated in place.
I think MSI can handle later upgrade of locked file on restart.. but then the goal is not achieved until restart.

I think we must build some installer with major version (only) in path to allow to test upgrade while running jvm before merging into master.