Inappropriate validation error about a missing java package that is in fact available in the JDK

[merks]

I was attempting to reproduce the problem described in this forum post:

https://www.eclipse.org/forums/index.php/mv/msg/1110468/

When one tries to launch the product generated for an RCP template (as detailed in the forum post), or when one invokes "Validate Plug-ins" from the Plug-ins tab, PDE complains like this:

But you can see that I have javax.xml.stream.StreamFilter open in an editor and you can see in the breadcrumbs that it comes from the my installed Java 11 JDK. So clearly the package exists.

[merks]

@HannesWell

I could not reproduce this from a self-hosted SDK IDE launch with all the lastest sources. Is this perhaps a problem that could have been fixed by changes you made in the last while?

[HannesWell]

@HannesWell

I could not reproduce this from a self-hosted SDK IDE launch with all the lastest sources. Is this perhaps a problem that could have been fixed by changes you made in the last while?

I did changes in the way which bundles are added to a launch, but this looks like a problem in the validation itself since that package should be provided by the JRE respectively the OSGi system-bundle (o.e.osgi), shouldn't it?
I did not change the validation itself. The closest change to the validation I did is this:
774c569

But this was actually only intended as a clean-up/simplification. But maybe this accidentally fixed some problems.

[merks]

@tjwatson

I could reproduce the problem when I set an RCP installation as the target platform. I think this issue is quite specific to javax.xml.bind_2.2.0.v201105210648 because it's one of the very few bundles with equinox_ee 9. When trying to resolve its package import of javax.xml.stream, the resolver finds 5 candidates, all from the system bundle, but there is none with equinox_ee == 9:

So later when checking isStatisfied,, all candidates are rejected:

This is the call stack:

I noticed in a number of places that Java 10 and higher are handled differently than Java 9 or lower by OSGi. That appears to be the cause of the problem here, but I have no clue how I might fix this. It does not appear to be a problem that can be fixed in PDE...

Thomas, do you have any hints/ideas about how I could try to fix this?

[tjwatson]

Thomas, do you have any hints/ideas about how I could try to fix this?

My guess is because I refused to keep adding more and more Java profiles after /org.eclipse.osgi/JavaSE-9.profile. Instead the framework calculates the available system packages using JPMS to discover the configured modules of the JVM. I know this disrupted some, including JDT and PDE that came to depend on these hard-coded files. I thought that both started calculating the packages similar to the framework.

[merks]

I misread what the ee numbers mean; they're an index in an array, so not meaningful with respect to Java version numbers.

The problem here is that the BREE of javax.xml.bind is 1.5 but it imports package javax.xml.stream which was introduced in Java 1.6 so the bundle itself is inherently inconsistent:

Manifest-Version: 1.0
Bundle-Vendor: %Bundle-Vendor.0
Bundle-RequiredExecutionEnvironment: J2SE-1.5
Bundle-Name: %Bundle-Name.0
Bundle-SymbolicName: javax.xml.bind
Eclipse-SourceReferences: scm:cvs:pserver:dev.eclipse.org:/cvsroot/too
 ls:org.eclipse.orbit/javax.xml.bind;tag=v201105210648
Bundle-Version: 2.2.0.v201105210648
Export-Package: javax.xml.bind;version="2.2",javax.xml.bind.annotation
 ;version="2.2",javax.xml.bind.annotation.adapters;version="2.2",javax
 .xml.bind.attachment;version="2.2",javax.xml.bind.helpers;version="2.
 2",javax.xml.bind.util;version="2.2"
Import-Package: javax.xml; version="[1.3,2.0)",javax.activation; versi
 on="[1.1, 1.2)",javax.xml.stream
Bundle-ManifestVersion: 2

I find it odd that this bundle can be started looking an RCP application, running with Java 11 of course:

34 ACTIVE javax.xml.bind_2.2.0.v201105210648

When PDE is validating though, it knows which EE version will be used in the launch and that makes me wonder if the validation shouldn't take that into account?

Of course all this also makes me wonder why the RCP package was never tested sufficiently to notice this problem. I'd open a bug/issue against orbit but it looks like this is bundle replaced by jakarta.xml.bind.

@tjwatson I don't suppose there is a simple way to specialize the validation so that it behaves more like it does at runtime? It doesn't seem worth to invest much effort in this though...

[tjwatson]

@tjwatson I don't suppose there is a simple way to specialize the validation so that it behaves more like it does at runtime? It doesn't seem worth to invest much effort in this though...

This multi-osgi-ee-profile stuff was added explicitly for PDE validation to ensure bundles don't start using packages that are not available at higher execution environments without pulling in a different provider of the package.

Perhaps the time for such a check has passed? I'm not sure how to relax that without simply removing all this multi-osgi-ee-profile stuff altogether when PDE resolves. What else would make sense?

[vogella]

IIRC the execution environments were not updated for latest versions and someone (@akurtakov ?) were planned to retire this functionality.

[merks]

No, everything seems up-to-date with respect to newer EE environments. In the end, the real problem is that java.xml.bind is simply wrong---the BREE contradicts the required packages---but I don't think anyone really ever developed it in a workspace as source plugin to notice it's wrong. So I'm not sure we should rip out stuff that's useful in other scenarios to deal with this exceptional case...

[HannesWell]

Isn't this a duplicate of #194?
Respectively @merks can you check if with the fix of that issue this is is resolved too?

[merks]

To test I added this to the Workspace.setup to force that IU into the target platform.

And I changed the launcher to include that bundle specifically:

There is no error message about it so it does seem to me the problem is fixed.

[HannesWell]

Thanks for checking. Then lets close this as completed. :)