System packages not found by validation

[ptziegler]

After updating to the Eclipse 4.26 (from 4.25), I get the following error when trying to launch our product:

Those packages come from the JDK, so they should be available to the product.

Tested with: OpenJDK 17.0.4+7 & 17.0.5+8 Eclipse SDK 4.26 & 4.27.I20230102-1800

Example: eclipse4.26-validation-error..zip

[ptziegler]

Note: The product starts normally when I click on "continue". I assume this is a false positive?

[HannesWell]

This is a resolution error in the Target-Platform. I noticed that as well already. When you look into the Target Platform State view, you will notice that the xml.resolver bundle (and probably also the other one) cannot be resolved due to the same errors (you can filter for unresolved Plug-ins in the burger-menu).

I can try to have a look at this soon.

[ptziegler]

I'd be great if you can find some time to look into this. As I said, it's more of an annoyance rather than a problem (and even then, I can always go back to the 4.25), but I assume more and more people will run into a similar problem, as they update their Eclipse installations.

[HannesWell]

I started to dig into this problem with a simple target:

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<?pde version="3.8"?>
<target name="xmlResolverTest">
    <locations>
        <location includeAllPlatforms="false" includeConfigurePhase="true" includeMode="planner" includeSource="true" type="InstallableUnit">
            <repository location="https://download.eclipse.org/releases/2022-12/"/>
            <unit id="org.eclipse.osgi" version="0.0.0"/>
            <unit id="org.apache.xml.resolver" version="0.0.0"/>
        </location>
    </locations>
</target>

Note (to myself, took me far too much time), the osgi system.package is important so that other bundles can resolve osgi.ee capabilities and JRE-packages! And an additional Plug-in in a debugged Eclipse Workspace that just has a simple manifest:

Manifest-Version: 1.0
Bundle-ManifestVersion: 2
Bundle-SymbolicName: test.ee.jre1.1
Bundle-Version: 1.0.0.qualifier
Require-Capability: osgi.ee;filter:="(&(osgi.ee=JRE)(version=1.1))"
Import-Package: javax.xml.parsers,
 javax.xml.transform,
 org.xml.sax

That Workspace-Plugin is a stripped-down variant of xml.resolver and shows the same errors in the Target-Platform state view.

When changing the required osgi.ee to Require-Capability: osgi.ee;filter:="(&(osgi.ee=JavaSE)(version=1.4))" or later (like 1.8, 11 or 17) the workspace Plugin resolves without errors.

Looking at the profile for the JRE-1.1 EE this is not surprising, because the list of system-packages is empty: https://github.com/eclipse-equinox/equinox/blob/415996e09ddac46f3e9e44fc60b4a622883d9a9c/bundles/org.eclipse.osgi/JRE-1.1.profile#L14

Consequently I think this is not a bug in PDE or but in the meta-data of the xml.resolver bundle. I wonder why xml.resolver does not require JavaSE 1.4 or later (which should be more than sufficient nowadays). This is likely related to the discussion in https://github.com/eclipse-pde/eclipse.pde/issues/130#issuecomment-1168510647 and one has to find-out why bnd generates a JRE-1.1 EE instead of one that can resolve. Because obviously the EE and import-packages don't fit together. But I'll leave that for tomorrow or the weekend.

[HannesWell]

The metadata are generated in Eclipse-Orbit at https://git.eclipse.org/c/orbit/orbit-recipes.git/tree/apache/org.apache.xml.resolver_1.2.0, which uses the maven-bundle-plugin, which under the hood uses bnd-tools to generate the metadata. Therefore maybe @bjhargrave knows immediately why JRE-1.1 is generated as EE, while at the same time system-packages are imported, which are not in that EE?

[bjhargrave]

Well the class file version are Java 1.1 (45), so the EE makes sense since it is computed from the highest class file version encountered.

As for any imports, if some class in the bundle uses a package which is not in the bundle, then you get an import. None of the imported packages above are java. so they look legit. javax.xml and org.xml don't have to come from the JRE. But any non-java. packages must be imported.

Bnd itself does not have a list of the non-java. packages in Java 1.1. https://github.com/bndtools/bnd/blob/master/biz.aQute.bndlib/src/aQute/bnd/build/model/JRE_1_1.properties. Java 1.1 is so old, I am not sure if anyone knows :-) So it is probable that the Eclipse validation tool does not know either.

[laeubi]

Consequently I think this is not a bug in PDE or but in the meta-data of the xml.resolver bundle. I wonder why xml.resolver does not require JavaSE 1.4 or later (which should be more than sufficient nowadays).

I don't think thats true, the bundle should not resolve against its declared profile but against the profile of the target, I really doubt your target has an effective EE of 1.1 of as org.eclipse.osgi already require a higher EE.

So unless you have your IDE using Java 1.1 as the default JRE, or have configured your target using EE 1.1 (then org.eclipse.osgi should fail validation), PDE is choosing the wrong profile for validating the plugin requirements.

So I assume the real EE should be 11 and that does not contain javax.xml.parsers,javax.xml.transform, org.xml.sax anyways, so it should be found by a plugin exporting it, but I can't see any in your target so validation is correct to fail.

[joeshannon]

I am also seeing this error after updating to 2022-12 IDE with javax.net and javax.net.ssl which are in the current (17) Java JDK.

(This is using xmlrpc from Orbit.)

[HannesWell]

Well the class file version are Java 1.1 (45), so the EE makes sense since it is computed from the highest class file version encountered.

As for any imports, if some class in the bundle uses a package which is not in the bundle, then you get an import. None of the imported packages above are java. so they look legit. javax.xml and org.xml don't have to come from the JRE. But any non-java. packages must be imported.

Is it really necessary in OSGi import non- java packages that are/can be provided by the JVM, for example org.xml.sax? At least in PDE with JDT I don't have to import that package in the manifest to be able to reference it in a Plugin and everything compiles fine. But maybe it is just a PDE+JDT specialty and it will blow up at runtime, haven't test that yet.

Bnd itself does not have a list of the non-java. packages in Java 1.1. https://github.com/bndtools/bnd/blob/master/biz.aQute.bndlib/src/aQute/bnd/build/model/JRE_1_1.properties. Java 1.1 is so old, I am not sure if anyone knows :-) So it is probable that the Eclipse validation tool does not know either.

Looks similar to Equinox. :) But yes I agree that Java 1.1 is way to old. I wonder if there is anybody besides museums that run such old JREs? 😄 The Equinox resolver relies on the information encoded into the corresponding profile in Equinox: https://github.com/eclipse-equinox/equinox/blob/415996e09ddac46f3e9e44fc60b4a622883d9a9c/bundles/org.eclipse.osgi/JRE-1.1.profile#L14

Because this profile is empty, the resolver is actually right, when it complains about unsatisfied imports.

Consequently I think this is not a bug in PDE or but in the meta-data of the xml.resolver bundle. I wonder why xml.resolver does not require JavaSE 1.4 or later (which should be more than sufficient nowadays).

I don't think thats true, the bundle should not resolve against its declared profile but against the profile of the target, I really doubt your target has an effective EE of 1.1 of as org.eclipse.osgi already require a higher EE.

No question a Java 1.1 JRE will not be used eventually. And yes one can specify a Java EE in the target or the default is used for that, but I have to check what exactly the default is (the selected 'main' installed JRE?). I think you have a point when saying that it should be resolved against the EE of the target, but it is very different to how it is handled at the moment and I first have to investigate that further and understand better why it is currently done differently. How is a OSGi runtime doing that at the moment? Just use the packages provided by the runtime's JVM?

On the other hand it actually works well at the moment and in the future. Only such really old configs (that are IMHO flawed) don't work. My first impulse was actually to suggest to use the noee instruction and specify the EE 'manually' to Java-1.4 (so that those that use really old Java-versions can use it).

EE's for higher java versions than the one of the target are probably not a concern since those bundles will not resolve due to the EE requirement (then packages are not the biggest problem). On the other hand IIRC all installed VMs known in the workspace are currently considered when setting up the properties of each profile. Therefore a bundle that requires Java-17 will probably resolve successfully even if the target's EE is Java-11 as long as there is a java-17 VM installation known to the workspace. But I have to check that. However I'm in doubt that this is a reasonable choice.

So I assume the real EE should be 11 and that does not contain javax.xml.parsers,javax.xml.transform, org.xml.sax anyways, so it should be found by a plugin exporting it, but I can't see any in your target so validation is correct to fail.

My JDK (GraalVM for Java-11 in this case) contains those packages.

[laeubi]

Is it really necessary in OSGi import non- java packages that are/can be provided by the JVM, for example org.xml.sax?

Yes, only packages starting with java.* are provided by the ExecutionEnvironment and even those are recommended to be imported in the light of modualar VMs.

At least in PDE with JDT I don't have to import that package in the manifest to be able to reference it in a Plugin and everything compiles fine.

This sadly is a (default enabled) legacy option of Equinox, you can enable true OSGi mode osgi.compatibility.bootdelegation=flase if I remember correctly, sadly PDE still do not contain a tooling option to enable this by default (I can't find the Bugzilla entry currently...)

And yes one can specify a Java EE in the target or the default is used for that, but I have to check what exactly the default is (the selected 'main' installed JRE?).

The default is the eclipse default JRE.

I think you have a point when saying that it should be resolved against the EE of the target, but it is very different to how it is handled at the moment and I first have to investigate that further and understand better why it is currently done differently.

That's why I think it is wrong :-D One issue is that (as you have noticed) PDE even needs "profile IU" in the target, what actually is also quite useless, so there is a mixture of things here.

How is a OSGi runtime doing that at the moment? Just use the packages provided by the runtime's JVM?

That's what is to be expected as far as I know if you not configure it differently.

Therefore a bundle that requires Java-17 will probably resolve successfully even if the target's EE is Java-11 as long as there is a java-17 VM installation known to the workspace.

What do you mean by resolve? Probabbly the pre-run check will succeed but such a bundle can never resolve against a Java11 target and will just remain in installed state.

[vogella]

Has this also be fixed by https://github.com/HannesWell/eclipse.pde/commit/e6ce4a318650d33123ee43d689e4bd6247245393 At least for me that javax.xml is not reported as missing in one of my clients projects which the recent I-build while the last release reports it as missing.

[joeshannon]

I am also seeing this error after updating to 2022-12 IDE with javax.net and javax.net.ssl which are in the current (17) Java JDK.

(This is using xmlrpc from Orbit.)

I am still experiencing this particular validation error when launching products in Eclipse 2023-06. Are there further improvements that can be made here or should we look at using a custom version of this plugin with modified metadata?

[merks]

I noticed problems like this the other day too setting up launchers to run BIRT's tests...

[HannesWell]

This now also poped up in Xtext with Guice 7: https://github.com/eclipse/xtext/issues/2717

Guice 7 uses

Import-Package: [...],sun.misc
Require-Capability: osgi.ee;filter:="(&(osgi.ee=JavaSE)(version=1.8))"

The JavaSE-1.8.profile in the org.eclipse.osgi bundle does not list sun.misc, so this is not a surprise.

So I see two options.

1. We fix the profiles in the o.e.osgi bundles as good as we can. Oracle provides a Java Archive that even lists 1.1: https://www.oracle.com/java/technologies/downloads/archive/ One needs an Oracle Account but can then download the archives for free. But those archives look quite different compared to today, but if one digs deep enough one can probably re-create the list of available packages.
   • Then there would be the question, which packages to include? Only those in the lib/rt.jar or also those in lib/tools.jar?
2. We use the suggestion from @laeubi and simplify resolve against the target JRE (which is most often the workspace default). This will work for modular JDK' for JavaSE-10 or later (for those for that we don't use the profiles provided by Equinox). But if one uses Java-9, Java-1.8 or even earlier as target in the workspace, then we have the same problem with incomplete profiles again. Or we would then need a way to query those older JDKs dynamically too.

[HannesWell]

Oracle provides a Java Archive that even lists 1.1: https://www.oracle.com/java/technologies/downloads/archive/

The content of the provided Java 1.2 download looks quite promising and listing all packages from the rt.jar is quite simple (other jars like tools.jar would be as simple, but I think rt.jar would be sufficient). I assume that more recent downloads will contain as man packages (or even more).

But the Java 1.1 download has much less packages in its rt.jar: When looking in SUNWjvdev\reloc\usr\java1.1\lib\rt.jar from https://download.oracle.com/otn/java/jdk/1.1.8_16/jdk-1_1_8_16-solaris-i586.tar.Z I only see the packages java., sun. and sunw., but nothing of the `javax.ororg.*package theorg.apache.xml.resolver` wants. Therefore I more and more think that the minimal JRE it specified is not correct. I might be true that the byte-code version says that but with the given information I assume that it was maybe compiled with a more recent JDK but used a target-version for the compiler of 1.1.

An alternative to fix this problem would probably be to either to re-generate the OSGi metadata for the xml.resolver artifactin Orbit or to get rid of org.apache.xml.resolver. As far as I know the JDK nowdays provides multiple XML parsers out of the box so it might be worth considering to migrate to them.

At least in my M2E workspace I only see the following bundles that depend on xml.resolver:

Maybe @merks can tell more about the entire SimRel? :)

The JDK already provides an XPath library: https://www.baeldung.com/java-xpath and AFAIK the Xerces parser is also part of the JDK. If those alternatives can be used, it would already allow org.eclipse.e4.emf.xpath and org.eclipse.wst.xml.core to get rid of xml.resolver and a few other libs in between. Then we only would have to check ant.

[laeubi]

The JavaSE-1.8.profile in the org.eclipse.osgi bundle does not list sun.misc, so this is not a surprise. We fix the profiles in the o.e.osgi bundles as good as we can.

I don't think there is something particular to fix here (but @tjwatson @bjhargrave can correct me if I'm wrong), but the profile has to list the officially specified packages that are provided by all compliant JVMs, sun.misc is a vendor specific package of Oracle JVM and therefore has to be provided by extra system packages and not by the profile!

So I think those manifests are generated automatically but no one has really tested them (e.g. on Java 1.1 OSGi framework/JVM) for that purpose or with other JVMs, regarding the Guice package I would simply mark the sun package as optional and take some actions to get rid of it altogether if running on different JVMs is a goal of the project.

[HannesWell]

sun.misc is a vendor specific package of Oracle JVM and therefore has to be provided by extra system packages and not by the profile!

In Theorie yes, but in practice I assume that this package is provided by most, if not all VMs. It is also in the OpenJDK. And looking the existing Profils there are already many packages listed that are not java.*. For example javax.*, org.omg.*, org.w3c.*. There is even org.ietf.jgss ??

So I think those manifests are generated automatically but no one has really tested them (e.g. on Java 1.1 OSGi framework/JVM) for that purpose or with other JVMs,

That's probably right, but from my experience projects that are not mainly intended to run in OSGi are not much interested in putting much effort in testing with OSGi.

regarding the Guice package I would simply mark the sun package as optional and take some actions to get rid of it altogether if running on different JVMs is a goal of the project.

I cannot mirgate guice of sun.misc(.Unsafe probably). If a good way would exist already I assume the guice-devs would have used it. Furthermore I think we cannot fix all Metadata out there.

However, can anyone tell if there is other Code that is using the list in org.osgi.framework.system.packages? If a change would harm Others we could simply hard code it into PDE up until Java 8 instead of reading the hard-coded list from equinox. For later JDKs we just continue reading it dynamically.

[merks]

Here are direct dependencies I see in SimRel:

[laeubi]

In Theorie yes, but in practice I assume that this package is provided by most, if not all VMs. It is also in the OpenJDK. And looking the existing Profils there are already many packages listed that are not java.. For example javax., org.omg., org.w3c.. There is even org.ietf.jgss ??

I just wanted to note that the profile is not necessarily "wrong" and only java.* packages are officially allowed to come from the Execution Environment see https://docs.osgi.org/specification/osgi.core/7.0.0/framework.module.html#framework.module-execution.environment

The Java environment provides all packages in the java.* namespace.

So every other package has to be imported and either be provided by extra system packages or other bundles, even though PDE still has the bug feature to offer more (e.g. javax.*) and do not complains this requires a special equinox specific property to be enabled to work!

This will work for modular JDK' for JavaSE-10 or later (for those for that we don't use the profiles provided by Equinox). But if one uses Java-9, Java-1.8 or even earlier as target in the workspace, then we have the same problem with incomplete profiles again.

I think JDT has some way to find the available packages, if one know them its not that hard to create a profile from that, that's actually what we do at Tycho already.

[merks]

To split hairs, that section also says "For Java platform versions prior to Java SE 9, the Framework must also set the org.osgi.framework.system.packages launching property to the list of Java platform packages generally known to be available at runtime." In the end, the org.osgi.framework.system.packages must/should be all the packages available in the Java runtime, i.e., packages that can be imported but are necessarily available via contributing bungles. Ideally it would be those actually available in the actual runtime being launched. Certainly all the profiles contain more than just java.* things, and if you look at any JustJ JRE

https://download.eclipse.org/justj/jres/11/downloads/latest/

It shows information about the actual value of org.osgi.framework.system.packages as computed by OSGi running on that runtime:

When PDE is launching something with Java 17, does it matter that some bundle says it runs with Java 1.1 and that the profile for 1.1 doesn't contain some specific package imported by that bundle? It seems to me that doesn't matter if Java 17 provides that package because that package will them be available for sure, even if it's not in Java 1.1...

[laeubi]

@merks correct but the important part is "the list of Java platform packages generally known to be available at runtime", so a fixed profile list can not satisfy this and therefore I have suggested to use the ones from the actual used JRE (thats closest to runtime we get I think), and JDT should help us somehow to get all packages from a JDK (@iloveeclipse ?) somehow as the compiler obviously knows there is such a package...

[merks]

Yes, that makes very good sense.

For JustJ I just kind of cheat and run this Ant script using the Ant runner in an Eclipse that is launched with each particular VM, letting OSGi compute its value:

<?xml version="1.0"?>
<project name="SystemProperty" default="build">
  <target name="build">
    <echoproperties/>
  </target>
</project>

In this case it's indeed better to reuse what JDT must have already computed somehow...

[gireeshpunathil]

a dumb question - will the resolver ever be able to know what packages are available in the target JVM that is not yet spwawned? even if it knows the JVM version?

[merks]

JDT knows that when it compiles code with any specific JRE...

[laeubi]

a dumb question - will the resolver ever be able to know what packages are available in the target JVM that is not yet spwawned? even if it knows the JVM version?

The JVM version is meaningless as of the support for modular JVMs (9+) anyways, but you add a JREs(!) in eclipse and that is the JVM used to execute it inside Eclipse, if you use another in your final product this might then produce failures to resolve but that's nothing solvable by the tooling.

[tjwatson]

a dumb question - will the resolver ever be able to know what packages are available in the target JVM that is not yet spwawned? even if it knows the JVM version?

The Java compiler knows because you can use --release option and it will complain if you reference APIs that do not exist in the target --release version. For that javac doesn't even need an installation of the JVM version being targeted. Somewhere it has information about the past versions.

[merks]

Note too though that one can create a JRE that reduces or expands the available modules so in the most general case, one can't hard code what OSGi computes when actually running in a particular JRE...

[HannesWell]

In Theorie yes, but in practice I assume that this package is provided by most, if not all VMs. It is also in the OpenJDK. And looking the existing Profils there are already many packages listed that are not java.. For example javax., org.omg., org.w3c.. There is even org.ietf.jgss ??

I just wanted to note that the profile is not necessarily "wrong" and only java.* packages are officially allowed to come from the Execution Environment see https://docs.osgi.org/specification/osgi.core/7.0.0/framework.module.html#framework.module-execution.environment

Maybe I didn't read the spec well enough, but I cannot see a paragraph that states that the org.osgi.framework.system.packages must only contain java.* packages? And as said the currently specified values already specify other packages not matching java.*.

But besides that I would like to recap what we are discussing about, because at least for me this issue is about two things:

1. The system-packages used for pre-launch validation
2. The system-packages used in the PDE-State for the workspace build, API-tools and Plugin/Product exports from the IDE.

For the Pre-Launch Validation it indeed makes sense to use the packages available in the VMInstall that will run the launch for all bundles regardless of their specified BREE/required osgi.ee, because this is what Equinox will then do, once the runtime is launched, isn't it? If a modular JDK (Java 9 or later) is used to laucnh PDE can read the jrt-fs.jar like already done in TargetPlatofrmHelper.querySystemPackages(), if it is a non-modular JDK (Java 8 or earlier), the rt.jar can be read.

For the second point, the PDE-State for the workspace build, API-tools and Plugin/Product exports from the IDE, we need the system-packages per Java-version, because as it was said by others we don't know at which Java version or even JDK flavour/Vendor the Plug-in eventually runs. If the BREE/required osgi.ee is Java 9 or higher we need a modular JDK in the workspace with at least that version for compilation and can then query the system-packages from it reading the jrt-fs.jar via TargetPlatofrmHelper.querySystemPackages(). And as far as I can tell this works reliably even if the required.ee is lower than the JDKs own Java version. This is because, as it was said, modular JDKs just 'knows' since when methods/packages are available to reliably work with the -release flag. But this only works for Java-9 and later and does not work when one queries a Java-9 or later JDK for the system packages of JavaSE-1.8 or earlier! Furthermore if one has a Java 1.8 or earlier JDK, it is not possible to query the JDK for the system-packages for any other than the JDKs Java version (i.e. by simplify walking the rt.jar). It think this is the reason why things like the Animal Sniffer Plug-in for Maven exists or compilation with Maven Toolchains was much more important for Java-1.8 or earlier.

So if there is a Plug-in project in the workspace that requires a non-modular (e.g. has BREE JavaSE-1.8) we cannot get the system-packages from a modular JDK reliably. If there is a VMInstall in the workspace that matches exactly the BREE, the system-packages could be read reliably from it walking its rt.jar. But if a BREE of Java 1.8 or earlier is used and there is no exactly matching VMInstall in the workspace we have to more or less guess the system-packages of that Java release. And for that guess I see two options:

1. Use the system-packages of the default or best-matching VMInstall for the EE.
   • If that is a modular JDK it could be considered to use the packages for JavaSE-9, assuming that only packages are added and not removed.
2. Hard code the list of system-packages in PDE and enhance the platform-properties of the PDE state with them as necessary. These lists can be derived from the rt.jar of the old Java releases at the Oracle archives as mentioned above. I assume the content of the rt.jar is similar even among different JDK vendors and that extra packages are provided in other system-jars? Changing Equinox is indeed not necessary/suitable.

The good thing is that devs that targets Java 1.8 or earlier likely have a corresponding VMInstall in their workspace and that non-modular JDKs will be used less and less over time so that problem will fade out.

[laeubi]

For the second point, the PDE-State for the workspace build, API-tools and Plugin/Product exports from the IDE, we need the system-packages per Java-version, because as it was said by others we don't know at which Java version or even JDK flavour/Vendor the Plug-in eventually runs.

A Target Platform is what PDE builds / checks against, and a target Platform always specify a JRE (most of the the workspace default) see here:

So this is the one that should be used and not some profile files for a completely different one.

Also I would highly discourage to write an own parser for packages, JDT should already offer anything we need here.

[HannesWell]

So this is the one that should be used and not some profile files for a completely different one.

I know that this exists, but in this point I have to say that I disagree. Using the same list of system-bundles for all Bundles in the PDE State (Target+Workspace) would contradict the flexibility OSGi offers with regard to the required EE. PDE can already determine the system-bundles for EE's >=Java-9 reliably. Why not improve the remaining ones (which will become less and less relevant over time) with a better default, that one can still override (by adding a VMInstall for a specific EE that can be checkcked)? The solution is not perfect, but I think it is definitely better than using the same system-packages for all Bundles in the PDE-State (for launches this is a different story as said).

Personally I also have never used a Target-EE/JRE and I have not seen anyone using it. Therefore I assume that this is not widely used and therefore often not carefully set up. Furthermore it looks like that the only effect this setting has at the moment is to set the workspace default JRE, when the target is activated: https://github.com/eclipse-pde/eclipse.pde/blob/e91bba596f39c894caa111f9316394d34e7bfc00/ui/org.eclipse.pde.core/src/org/eclipse/pde/core/target/LoadTargetDefinitionJob.java#L167

The description also indicates this purpose. I don't think it is a good idea to change its purpose.

Also I would highly discourage to write an own parser for packages, JDT should already offer anything we need here.

Yes definitely, I just mentioned that for more clarity. Nevertheless I don't know if JDT offers everything exactly as we need it since even in TargetPlatformHelper.querySystemPackages needs to do some work. I already suggested to improve JDT in this regard (https://github.com/eclipse-jdt/eclipse.jdt.debug/issues/175) but didn't have the time to complete that yet.

[laeubi]

I know that this exists, but in this point I have to say that I disagree. Using the same list of system-bundles for all Bundles in the PDE State (Target+Workspace) would contradict the flexibility OSGi offers with regard to the required EE.

There is only one state so there should only be one VM that contributes system packages, I don't see how this would contradict any flexibility? Also as said the required EE only contributes java.* packages, the system packages are contributed by a concrete runtime JRE and that's the one selected as a target JRE.

This already created some problems in the past where javax.* packages where removed and PDE happily assumed they are still provided just because the bundles uses JavaSE-1.8 but has no imports for them, then your bundle fails on the runtime (or in a Tycho build that detects this situation).

So if one really wants to improve something, then one needs have one PDE state per project and then use the JRE of the project, but using different JREs across a global state can only lead to false results as we already see here.

Personally I also have never used a Target-EE/JRE and I have not seen anyone using it. Therefore I assume that this is not widely used and therefore often not carefully set up.

This is not really an argument, as said often people are happy with the default JVM in their Eclipse and this is used to run and verify everything, beside that Tycho is already reading this value and using it for target resolution.

[HannesWell]

The PR https://github.com/eclipse-pde/eclipse.pde/pull/693, which aims to fix this issue is now almost ready. I implemented a hybrid approach, described in the PR's initial comment that considers Christoph's suggestion but allows the user to influence the system-packages in the PDE-state and therefore is IMHO a good balance probable accuracy, convenience and the possibility to let the user control the result. Because in the end one can only be really sure about the available system-packages at runtime. At any other time, e.g. during development in the Eclipse IDE one can only guess/assume what's available and the implemented approach seems to be the most reasonable guess.

[HannesWell]

If nobody objects I plan to submit the PR latest on Saturday.

[ptziegler]

I've tested the latest nightly build and can confirm, the dialog no longer shows up. Thank you a lot for working on this!

[HannesWell]

I have just submitted another refinement via https://github.com/eclipse-pde/eclipse.pde/pull/714 that aims to handle the case of a malformed VM being selected and queried initially. Everyone interested in this change: please try tonight's (or later) I-build and report any regressions you encountered.