Enhance computation of system-package provided by a ExecutionEnvironment

[HannesWell]

Fixes #429

• Only consider EE of running VM in launch validation to match the behavior later at runtime

• For the PDEState the EE's system-package is computed with the following distinction:

  • for a EE that corresponds to a Java-9 or higher release, get the 'best matching' VMInstall and query the system-packages for the EE's java release version (which is possible for modular JVMs)
  • for a Java-8 or lower release check if there is a VMInstall selected/strictly compatible to that version and query the system-packages from that VM (i.e. its rt.jar and other libraries)
  • if there is no VMInstall for a for a Java-8 or lower release, combine the hard-coded list of 'java.*' packages with the set of
    non-java packages provided by the default VMInstall of the workspace. The default VMInstall of the WS is at the same time the JVM selected in the active target definition (which sets its selection as WS default upon loading).
  • In general the available system-packages are only really known at runtime. Therefore at any other time, e.g. in the workspace one can only guess/assume what packages are available and the implemented algorithm seems to be the best trade-off between probable accuracy, convenience and the possibility to let the user control the result.

• Listen to changes of available VMInstalls and ExecutionEnvironment defaults. Re-read them on changes and re-resolve the PDE-State again with a subsequent re-validation of all Plugin projects.

@laeubi in case one only has one JRE in the WS respectively none set as default of a EE, this is equivalent to your suggestion to just use the TP's JRE. This is convenient, but at the same time allows to be more specific if desired by providing/setting a JRE for an EE.

In my local testing that replicated the guice case, this worked well.

This is currently a draft since the list of java-packages still has to be completed. I'm on vacation for a week now, but will complete this once I'm back.

[github-actions]

Test Results

     246 files  ±0       246 suites  ±0   58m 49s ⏱️ - 1m 34s
  3 299 tests +1    3 275 ✔️ +3  24 💤 ±0  0 ❌ ±0 
10 194 runs  +3  10 122 ✔️ +5  72 💤 ±0  0 ❌ ±0 

Results for commit b84ab4f. ± Comparison against base commit 8435fdd.

♻️ This comment has been updated with latest results.

[HannesWell]

I now enhanced this:

• Added a test-case and adapt existing test cases
• Add a listener to be notified about changes in the Java -> Installed JREs (->Execution Environment) preferences and trigger a re-read of system-packages then followed by a re-resolve and re-validation of all Project Manifests.
• Use EE profiles file for Equinox's o.e.osgi for those cases if they contain the correct list of java.* packages (all other packages are ignored).
  • The listed java.* packages are in all cases, except for JRE-1.1 and J2SE-1.2, de-facto the same as those I extracted from ancient JDKs. The only difference is that I found the packages [java.awt.dnd.peer, java.awt.peer], but they seem not to be interesting for application developers. At least the doc says the following, which is why I assume it is fine to skip them.

The peer interfaces are intended only for use in porting the AWT. They are not intended for use by
application developers, and developers should not implement peers nor invoke any of the peer
methods directly on the peer instances.

[HannesWell]

@gireeshpunathil you maybe want to back-port this If we don't encounter problems with this in the next week.

[gireeshpunathil]

thanks @HannesWell. sure, will do.