Java Reference
In-Depth Information
that you supply a bundle name and version, and it wires you to every exported package
from that bundle. Unlike Import-Package: , Require-Bundle doesn't cause any code
inside your bundle to be shadowed. This means that your bundle can see its original
content and the required bundle's content for the split package, effectively combining
them into one.
What do we mean by shadowing?
If a bundle contains a package without exporting it, and also imports it, the contained
code will never be loaded. The semantics of OSGi classloading state that the load of
any resource from an imported package is delegated to the exporting bundle to which
you were wired. The content from the exporter shadows the entire content of the pack-
age inside the importing bundle, meaning that the contained content can't be loaded
even if there's no corresponding resource in the exporting bundle. If you ever see a
ClassNotFoundException for a class you know is in your bundle, then this is prob-
ably what has happened.
Require-Bundle doesn't cause shadowing of entire packages, but it can cause
shadowing of individual resources. As with imported packages, required bundles are
searched before the classpath of the bundle. This means that if a resource is present
in a required bundle, then it overrides that resource inside the bundle that requires
it. This can cause major problems if the resources in the two bundles aren't the
same, or even if they are. When classes are loaded, their identity is defined by the
java.lang.ClassLoader that loads them; this means that classes from required
bundles are in a different package! This can cause havoc with default or protected
visibility methods.
Using Require-Bundle , you can make one of the bundles export the entirety of the
package. By adding an attribute with a mandatory constraint to the required bundle's
export of the split package, importers of that package no longer need to worry about
accidentally getting wired to the wrong export (see figure 5.5). (We'll look at the man-
datory directive in more detail in section 7.1.3.)
Bundle-SymbolicName: A
Import-Package: fancyfoods.split
Bundle-SymbolicName: B
Require-Bundle: C
Export-Package: fancyfoods.split
Bundle-SymbolicName: C
Export-Package: fancyfoods.split; partial="true"; mandatory:="partial"
The use of Require-Bundle and mandatory attributes can eliminate the ambiguity
created by the split packages, but it significantly reduces the modularity and flexibility
of your application. The two halves of your split package are forever tightly tied
together, and the whole thing is rather unpleasant. We hope that you agree with us
that split packages are better off avoided!
 
Search WWH ::




Custom Search