Mastering modularity - OSGi in Action - page 56

import
org.foo.shape

import
javax.swing

Main API Swing

export
org.foo.shape

export
javax.swing

Figure 2.16 Transitive bundle-resolution wiring

What does the wiring in figure 2.16 tell you? It says that when the main bundle needs
a class in package org.foo.shape , it gets it from the shape API bundle. It also says
when the shape API bundle needs a class in package javax.swing , it gets it from the
Swing bundle. Even though this example is simple, it's largely what the framework
tries to do when it resolves bundle dependencies.

System class path delegation
In actuality, the javax.swing case in the previous example is a little misleading if
you're running your OSGi framework with a JRE that includes javax.swing . In such
a case, you may want bundles to use Swing from the JRE. The framework can pro-
vide access using system class path delegation. We'll look at this area a little in
chapter 13, but this highlights a deficiency with the heavyweight JRE approach. If
it's possible to install a bundle to satisfy the Swing dependencies, why are they
packaged in the JVM by default? Adoption of OSGi patterns could massively trim the
footprint of future JVM implementations.

You've learned that you can have attributes attached to exported and imported pack-
ages. At the time, we said it was sufficient to understand that attributes attached to
imported packages are matched against attributes attached to exported packages.
Now you can more fully understand what this means. Let's modify the bundle meta-
data snippets to get a deeper understanding of how attributes factor into the resolu-
tion process. Assume you modify the Swing bundle to look like this:

Bundle-Name: Swing
Export-Package: javax.swing; vendor="Sun"
Here, you modify the Swing bundle to export javax.swing with an attribute vendor
with value "Sun" . If the other bundles' metadata aren't modified and you perform the
resolve process from scratch, what impact does this change have? This minor change
has no impact at all. Everything resolves as it did before, and the vendor attribute
never comes into play. Depending on your perspective, this may or may not seem con-
fusing. As we previously described attributes, imported attributes are matched against
exported attributes. In this case, no import declarations mention the vendor attribute,
so it's ignored. Let's revert the change to the Swing bundle and instead change the
API bundle to look like this: