Java Reference
In-Depth Information
It's not important for you to completely understand these arcane details of Java class
loaders, especially because
OSG
i technology tries to relieve you from having to worry
about them in the first place. The important point is to understand the issues sur-
rounding the two options: option 1 results in bundle C requiring B to be present,
whereas option 2 results in bundle A not being able to see the shared object instances
from bundles B and C at the same time. This gets us to the crux of
OSG
i's special case
for allowing a bundle to import a package it exports.
Neither of the previous two options
is satisfactory. The solution devised by
the
OSG
i specification is to allow a bun-
dle to both import and export the same
package (see figure 5.3). In this case,
the bundle contains the given package
and its associated classes, but it may not
end up using its copy. A bundle import-
ing and exporting the same package is
offering the
OSG
i framework a choice; it
allows the framework to treat it as either
an importer or an exporter of the pack-
age, whichever seems appropriate at the
time the framework makes the decision.
Here's another way to think about this:
it defines a
substitutable
export, where
the framework is free to substitute the bundle's export with an imported package from
another bundle. Returning to the example, both bundles B and C can include a copy
of package
javax.servlet
, with both importing and exporting it, knowing they'll work
independently or together.
Admittedly, this may seem odd; but as the discussion here illustrates, to simplify
the
OSG
i vision of a collaborative environment, it's necessary to make sure bundles
use the same class definitions. Up until the
OSG
i R4 specification,
Export-Package
implicitly meant
Import-Package
, too. The R4 specification removed this implicit-
ness, making it a requirement to have a separate
Import-Package
to get a substitut-
able export; but this didn't lessen the importance of doing so in cases where
collaboration is desired. An interesting side effect of this is the possibility of metadata
like this:
C
.cl
as
s
B
export and import
javax.servlet
.class
export and import
javax.servlet
A
import
javax.servlet
Figure 5.3
B and C can both export and import the
Servlet
package, which makes it possible for the
framework to choose to substitute packages so all
bundles use a single class definition.
Export-Package: javax.servlet; version="2.4.0"
Import-Package: javax.servlet; version="2.3.0"
This isn't a mistake. A bundle may include a copy of a given package at a specific ver-
sion but may work with a lower range. This can make the bundle useful in a wider
range of scenarios, because it can still work in an environment where an older version
of the package must be used.
