Community
Participate
Working Groups
For the osgi bundle, the classpath contains two special jars through the bootclasspath properties inside the build.properties: bootClasspath=osgi/exceptions.jar;osgi/xmlParserAPIs.jar;${CDC-1.1/Foundation-1.1} These two jars provide types in java.nio packages as well as xml types. When we resolve references to these types inside the osgi component, we return them as being found in the system library api component. This is wrong for this bundle. Inside org.eclipse.pde.api.tools.internal.model.ApiBaseline.resolvePackage(IApiComponent, String), we first check for system packages. We should first check the extra jars on the bundle classpath in the order they appear. In this case, the two jars appears before the system library entry. Even if I remove that check, we don't resolve these entries against one of the two jars. As long as this is not fixed, the new system api detection returns lots of false positives for this bundle.
The OSGi bundle is doing some compile/runtime trickery here... the extra bootclasspath entries in build.properties allow the bunlde to compile, but the classes may/may not be available at runtime. I beleive these are real illegal access errors that should be flagged, since the classes are not on the bundle's classpath. The errors should be filtered by the bundle as known API problems. At runtime the classes do come from the system library, so our analysis is correct.
