The Author Online Book Forums are Moving

The Author Online Book Forums will soon redirect to Manning's liveBook and liveVideo. All book forum content will migrate to liveBook's discussion forum and all video forum content will migrate to liveVideo. Log in to liveBook or liveVideo with your Manning credentials to join the discussion!

Thank you for your engagement in the AoF over the years! We look forward to offering you a more enhanced forum experience.

evatroels (1) [Avatar] Offline
At page 221 in the newest version you write: "Looking at the OSGi headers, our jEdit bundle doesn't export
any packages, but it does need packages from Swing and SAX. These are typically provided by the system bundle, although not always. Sometimes you need to provide alternative versions of JDK classes like Swing."

I am curious as to how it is possible to provide alternative (bundle specific) versions of for instance Swing.

Could you provide me with pointers?

Eva Troels
stuart.mcculloch (29) [Avatar] Offline
Re: Alternative versions of JDK classes like Swing
Ch2 discusses OSGi classloading, where any package that doesn't start with "java.*" can be loaded from another bundle - rather than follow the classic check-parent-first delegation model. This means that extension and framework packages under javax can have multiple alternative versions, just like any other non-"java.*" package in OSGi.

So for example, there's an alternative implementation of Swing available here:

which could be wrapped into a bundle and have it's javax packages exported under a different version, or with a different attribute. Then all you'd need to do to pick up this version of Swing instead of the JDK version is put the relevant version/attribute on your Import-Package metadata.