Java Reference
In-Depth Information
Having read the information in this section, you'll likely agree that structuring a bun-
dle isn't too difficult. The skills you've developed writing Java objects are completely
transferable, and once you get a feel for it you'll recognize a bad bundle in seconds.
One important gotcha, which might seem perfectly innocuous and could easily be
missed, is the cause of some of the most awkward headaches in
OSG
i development.
This problem is called the
split package
.
THE PROBLEM WITH SPLIT PACKAGES
A split package is what you have when two bundles contain
and export
different bits of
the same package at the same version. Although
OSG
i is well equipped to handle cases
where the same package is exported by several bundles, the assumption is that the pack-
age implementations are interchangeable. Particularly, if two bundles export the same
package at the same version, the
OSG
i framework could wire you to either. Importantly,
the framework will only ever wire an importing bundle to one of the exported packages.
When a split package isn't a split package
If a bundle imports a package and contains extra bits of that package without export-
ing it, it isn't a split package. This is known as
shadowing
. Shadowing can cause as
much of a mess as split packages, if you're not careful. We'll discuss shadowing
more in a moment.
This works well when the packages are indeed interchangeable, but it can produce
unexpected effects when different bundles claim to export the same package but con-
tain different classes. Only the classes from the bundle you wire to will be visible at
runtime! See figure 5.4.
B
fancyfoods.split.Foo.class
A
Import-Package:
fancyfoods.split
OR
C
fancyfoods.split.Bar.class
Figure 5.4
An importing bundle can only wire to a single instance of an exported package. If this
client needs
fancyfoods.split.Foo
, then you have a 50:50 chance of success. If it needs both
fancyfoods.split.Foo
and
fancyfoods.split.Bar
, then it can never work.
