OOmph uses outdated JDK path after JDK update

[jukzi]

After JDK updates itself i always run into several error, because Eclipse Adoptium's path changes after update.
So after eclipse stopped working (which is understandable) i tried to setup a fresh OOmmphed workspace. But it kept using the outdated path for "JRE 17 Location"
I had to manually "Show all variables" and change the JDK location.

surprisingly Oomph seems to know that the old version does not exists anymore (was not selectable as JVM) but still auto-selected it by default :-(
In such a case it would be nice if OOmph would automatically select a valid path only or actively asks about a valid location.

[merks]

I"m not sure how feasible that is. The previous choices are recorded in the user.setup (Navigate -> Open Setup -> User):

One cannot generally know that some task will not create the specified folder while performing...

[merks]

BTW, I assume you likely get other types of problems, i.e., that IDEs fail to start because the -vm option in the eclipse.ini points to a JRE that's been deleted. Is that the case too?

[jukzi]

bunch of other problems: yes. eclipse itself runs but jdt failed to compile stating for example java.lang.Object not found and many more

[merks]

This is why I never use the JDK installers because I really can't abide the potential have having ~100 installations become broken. Of course that's no consolation to those who do. Also, because folks don't generally read information that's presented to them, I'm not sure how to prompt a user to update the JRE location. E.g., isNeeded could return true when the JRE folder doesn't actually exist and then the task could fail with a message saying the JRE folder doesn't exist. But how to get the user to actual fix it, i.e., go to the variables page and show all variables and change the value. Or edit the user setup?

[basilevs]

Eclipse IDE for Eclipse Committers 2024-06 would not launch on Java 25, yet Eclipse Installer suggests Java 25 as a choice:

Is it for the same reason - previous user selection has to be selectable even if it is not compatible?

[merks]

The concern in this issue is the JRE used for the JRE task and the fact that this is recorded (in the user.setup) and then subsequently one might deleted the JDK itself such that the recorded value for a Java Mn chosen previously is bogus.

Here you discuss the JDK choice for the installation which is not directly related, though similar. Unfortunately Java is not as backward compatible as one might hope. Some options that one might use with Java 21, e.g., -Djava.security.manager=allow might make Java 25 not start. Also unfortunate is that the overall design with BREE in MANIFEST.MF and with -Dosgi.requiredJavaVersion=21 at launch time is focused on a lower bound. So we can't really know looking at any information in any resource anywhere that the older IDE won't start on Java 25 and there is nothing implemented in Oomph set an upper bound.

I have changed the installer to pick the closest matching version rather than the highest version for this reason, but even the installer has recall about choices you've made.

---

Note that removing -Djava.security.manager=allow allows it to start with Java 25. (I just tested that.) But I'm not saying it works well!