Select the best matching JRE for an EE from the list of compatible JVMs

[laeubi]

Currently the selection of a compatible JRE for an EE seems quite random for the user, e.g. it can happen that for an EE10 with some JRE11/17/24 it chooses 24. This is actually a bad choice as newer java might remove API during release, so the lowest possible java version among others would be the best choice here.

This now do the following:

• introduce a new method IExecutionEnvironment#getCompatibleVM that selects the best matching from the set of selected JVMs (but ignoring the default)
• in the JREContainerInitializer check if there is a default vm selected, then use that
• if not ask the EE for a compatible one (with the new method)

See

• Selection of "best matching" JRE is inconsitent (if not wrong) #760

[SougandhS]

Unrelated test failure : #719

[laeubi]

@stephan-herrmann how is the plan to proceed here? It seems we missed the M3 deadline already whats a bit unfortunate as it makes the MR feature a bit hard to use without launching support. All checks are green so can we possibly consider this for RC1?

[stephan-herrmann]

@stephan-herrmann how is the plan to proceed here? It seems we missed the M3 deadline already whats a bit unfortunate as it makes the MR feature a bit hard to use without launching support. All checks are green so can we possibly consider this for RC1?

I'm sorry for missing deadlines, but please understand that I had and have also other issues on my plate.

At this stage what you'd need is a JDT lead who champions this as a bugfix (not feature work) meeting the criteria of RC1 (which I personally think will be difficult to argue). I'm not a lead, so it won't be me. Also I haven't really reviewed this particular PR yet.

[laeubi]

I'm sorry for missing deadlines, but please understand that I had and have also other issues on my plate.

That wasn't a criticism, I just noticed the mail about M3 on the dev list and remembered this ticket was still open and as I was away some time due for medical reasons I also was not able to further drive this forward. So I just wanted to know if there are any plans or if we there is a chance to get this still resolved for this release.

At this stage what you'd need is a JDT lead who champions this as a bugfix (not feature work) meeting the criteria of RC1 (which I personally think will be difficult to argue)

Yes I think you are right, while this one could maybe be argued as a bug it is nothing urgent (as no one really complained for a long time) and its also not a regression (it is failing since a long time).
Also the dependent PR #753 can barley be seen as a bugfix as it clearly relates to a new feature so it seems best to to just delay it to the next release than trying to rush things in.

Also I haven't really reviewed this particular PR yet.

If you know someone else please give a suggestion, I just have the feeling due to the context you seem the most suitable person for this, but its of course not limited to you of course.

[laeubi]

@jjohnstn can you probably help in review this? Or @stephan-herrmann could help out? I think it would be good to have this as early as possible in the development cycle to find possible problems with the new approach.

[jjohnstn]

@jjohnstn can you probably help in review this? Or @stephan-herrmann could help out? I think it would be good to have this as early as possible in the development cycle to find possible problems with the new approach.

@laeubi Missed this. Will look at it.

[jjohnstn]

Looks good. The old code would return the first installed VM if nothing compatible was found but that isn't correct and the code should force the end-user to install an appropriate JRE.

[laeubi]

Thanks for looking into this!