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.

[Okeanos]

As the one who originally created #422 and looks very much forward to getting this solved, I am wondering what has to happen so this PR gets looked at & approved?

[karianna]

Also see #983

[karianna]

@adipiciu Would you be able to resolve the merge conflict / rebase?

[sxa]

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

Noting that Red Hat's installer is the same as Temurin (It goes into C:\Program Files\RedHat\java-21-openjdk-21.0.4.0.7-1 for the latest release), so there is precedent both ways

[adipiciu]

@karianna Sorry, you can close this PR. I can't wait 1 year for these guys to take a decision.
@Okeanos You can use msiexec /i "msifilename.msi" INSTALLDIR="C:\Program Files\Eclipse Adoptium\jre-8-hotspot" or whatever fixed name you want. Or even use Zulu, Corretto or Liberica builds which already have fixed paths.

[Okeanos]

@adipiciu thanks for initially working on this first of all and thank you also for your suggestion. I know that I can override the default location when invoking the installer (and routinely do so). My goal was to make all of this smoother for automated processes, especially considering e.g. winget where it is not guaranteed that the Temurin manifest exposes this switch all the time.

Would it be okay for me to reuse the changes you proposed in your PR to create a new one? I would attribute these changes to you, of course.

@karianna, @douph1, @sxa could you give us a rough outline here what still has to be decided/what official outcomes are which need to be incorporated into a new PR?

[karianna]

@adipiciu thanks for initially working on this first of all and thank you also for your suggestion. I know that I can override the default location when invoking the installer (and routinely do so). My goal was to make all of this smoother for automated processes, especially considering e.g. winget where it is not guaranteed that the Temurin manifest exposes this switch all the time.

Would it be okay for me to reuse the changes you proposed in your PR to create a new one? I would attribute these changes to you, of course.

@karianna, @douph1, @sxa could you give us a rough outline here what still has to be decided/what official outcomes are which need to be incorporated into a new PR?

That would be welcome - I think given #983 let's start with what was proposed here: #789 (comment)