This is a variant of
and discovered here
As described in the issue:
even without any multi-release configuration there is no 100% guarantee that a higher JVM matches the exact behavior of the selected version; think of any modules / classes / methods that are effectively removed from a JVM at a higher version, whereas the selected lower version would still have it
This implies that when selecting a JRE for a given EE, the risk that something is removed or changes is higher the larger the gap is between the desired runtime and a perfect match.
But currently org.eclipse.jdt.internal.launching.JREContainerInitializer.resolveVM(IExecutionEnvironment) has some code that simply selects the default JVM if it matches regardless of other choices. If that one do not match it even select the first (what is random as it only depends on in what order installs are added). So assume we want a EE11 and have a default JVM of Java 24 and another one of Java 12 the java 24 is chosen that at has a much higher chance of removal that Java 12.
Also this is not reflected elsewhere, e.g. org.eclipse.jdt.internal.debug.ui.jres.JREsEnvironmentComparator only sort by perfect match and then by name of the JRE giving a false impression of ordering in the UI. The we have org.eclipse.jdt.internal.ui.refactoring.reorg.PasteAction.TextPaster.computeLatestVM() that already uses an ordering of jvms to find the best matching (that is the first with lowest).
Because of this I think we should have a new method as an alternative to EE.getCompatibleVMs() that is EE.getCompatibleVM() and adhere to the rule of returning the lowest compatible JVM, then also JREsEnvironmentComparator should be adjusted to reflect this ordering as well, so that the most likely selected one is first regardless of name.
This is a variant of
and discovered here
As described in the issue:
This implies that when selecting a JRE for a given EE, the risk that something is removed or changes is higher the larger the gap is between the desired runtime and a perfect match.
But currently
org.eclipse.jdt.internal.launching.JREContainerInitializer.resolveVM(IExecutionEnvironment)has some code that simply selects the default JVM if it matches regardless of other choices. If that one do not match it even select the first (what is random as it only depends on in what order installs are added). So assume we want aEE11and have a default JVM ofJava 24and another one ofJava 12the java 24 is chosen that at has a much higher chance of removal thatJava 12.Also this is not reflected elsewhere, e.g.
org.eclipse.jdt.internal.debug.ui.jres.JREsEnvironmentComparatoronly sort by perfect match and then by name of the JRE giving a false impression of ordering in the UI. The we haveorg.eclipse.jdt.internal.ui.refactoring.reorg.PasteAction.TextPaster.computeLatestVM()that already uses an ordering of jvms to find the best matching (that is the first with lowest).Because of this I think we should have a new method as an alternative to
EE.getCompatibleVMs()that isEE.getCompatibleVM()and adhere to the rule of returning the lowest compatible JVM, then alsoJREsEnvironmentComparatorshould be adjusted to reflect this ordering as well, so that the most likely selected one is first regardless of name.