| Re: [equinox-dev] Bug 566085 - javax.annotation package-uses problems with Java 8 |
Hi Neil,
somehow I have the feeling, this problem can be solved in a
different way.
If the osgi.framework.system.packages / extra is provided including a version qualifier for JavaSE-1.8. Mostly, I see, if provided at all, that these definitions are provided without version attribute.
If I understand it correctly in
https://docs.osgi.org/specification/osgi.core/7.0.0/framework.module.html#framework.module.resolvingprocess.
The resolver preference priorities are resolved exporter before unresolved exporters and then versioned exports before un-versioned.
That would mean that the system-bundle with system.packages is
always resolved, and would preferred before other bundles. If then
also a correct version is provided in the system.packages, it
should be the preferred wire before all others.
Adding an Import-Package, where an Export-Package exist, could also lead to the situation, where the Import-Package is ignored by the framework:
Or am I missing something here?
Regards,
Mark
I'm not sure that class loading order is even relevant here. The stack trace linked by Brian was an OSGi resolution error... resolution happens before a Bundle ClassLoader is constructed and therefore before the bundle attempts to load any class name.
Neil
On Sat, 22 Aug 2020 at 09:50, Mark Hoffmann <mark.hoffmann@xxxxxx> wrote:
_______________________________________________Hi,
I dont think that this is final solution for that problem.
The class finding search order is defined in OSGi:
That mean finding a class to be loaded will be initially done using the boot delegation (Step 2 in this case). If defined correctly the following will happen:
Java 1.8 - delegate to parent class loader an load javax.annotation from there (no matter, if you have an bundle provided for that package)
Java 11 - cannot find javax.annotation over boot-delegation, go on with Import-Package or Require-Bundle
Either provide a org.osgi.framework.bootdelegation=javax.* as property to activate boot-delegation or you can use the existing profiles instead.
The Profiles are defined in Equinox:
You can find the property: org.osgi.framework.bootdelegation there with a definition for javax.*
To make Equinox use this profile (I dont know, if this happens by default) via launcher, you should provide the osgi.java.profile="" moz-do-not-send="true">file:/<your-path>/JavaSE-1.8.profile
If you take the profile, then you have to additionally provide the property: osgi.java.profile.bootdelegation=override, so that Equinox takes the profile boot delegation entries. instead of already defined ones
With the correct boot-delegation configuration, always that same class loader will be taken for this constellation, no matter, if in Java 1.8 or 11. The same applies to JAXB problems.
https://wiki.eclipse.org/Equinox_Boot_Delegation
Regards,
Mark
Am 21.08.20 um 22:43 schrieb Brian de Alwis:
Unfortunately javax.annotation package-uses issues have returned :(
The effort to replace the no-longer maintained Spotify Docker Client (bug 558284) introduced a new version of the javax.annotation bundle into Orbit based on Jakarta EE’s somewhat recently released javax.annotation bundle with version 1.3.5. This bundle doesn’t use the same approach used for the javax.annotation 1.2.0 bundle to use import-what-you-export and requiring system.bundle.
The issue only occurs on Java 8 and has been seen in the wild. I suspect it has not been more widespread due to increased adoption of Java 11.
I’ve pushed up a fix to the javax.annotation 1.3.5 bundle. I think the risk is small, but given that we’re in RC season, it would be good to get some more eyes on this.
If you have concerns, please comment on Bug 566085.
Brian.
_______________________________________________ equinox-dev mailing list equinox-dev@xxxxxxxxxxx To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/equinox-dev-- Mark Hoffmann E-Mail: mark.hoffmann@xxxxxx
equinox-dev mailing list
equinox-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/equinox-dev
_______________________________________________ equinox-dev mailing list equinox-dev@xxxxxxxxxxx To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/equinox-dev
-- Mark Hoffmann E-Mail: mark.hoffmann@xxxxxx