Java Reference
In-Depth Information
(continued)
Package-level dependencies represent a higher-level view of the code's real class de-
pendencies. It's possible to analyze a bundle's code and generate its set of imported
packages, similar to how IDEs maintain import declarations in source files. Module-
level dependencies can't be discovered in such a fashion, because they don't exist
in the code. Package-level dependencies sound great, right? You may now wonder if
they have any issues.
The main issue is that OSGi must treat a package as an atomic unit. If this assump-
tion weren't made, then the OSGi framework wouldn't be free to substitute a package
from one bundle for the same package from another bundle. This means you can't
split a package across bundles; a single package must be contained in a single bun-
dle. If packages were split across bundles, there would be no easy way for the OSGi
framework to know when a package was complete. Typically, this isn't a major limi-
tation. Other than this, you can do anything with package-level dependencies that you
can with module-level dependencies. And truth be told, the OSGi specification
does
support module-level dependencies and some forms of split packages, but we won't
discuss those until chapter 5.
2.5.4
Class-search order
We've talked a lot about code visibility, but in the end all the metadata we've discussed
allows the
OSG
i framework to perform sophisticated searching on behalf of bundles
for their contained and needed classes. Under the covers, when an importing bundle
needs a class from an exported package, it asks the exporting bundle for it. The
framework uses class loaders to do this, but the exact details of how it asks are unim-
portant. Still, it's important to understand the ordering of this class-search process.
When a bundle needs a class at execution time, the framework searches for the
class in the following order:
If the class is from a package starting with
java.
, the parent class loader is asked
for the class. If the class is found, it's used. If there is no such class, the search
ends with an exception.
1
If the class is from a package imported by the bundle, the framework asks the
exporting bundle for the class. If the class is found, it's used. If there is no such
class, the search ends with an exception.
2
The bundle class path is searched for the class. If it's found, it's used. If there is
no such class, the search ends with an exception.
3
These steps are important because they also help the framework ensure consis-
tency. Specifically, step 1 ensures that all bundles use the same core Java classes, and
step 2 ensures that imported packages aren't split across the exporting and import-
ing bundles.
That's it! We've finished the introduction to bundle metadata. We haven't covered
everything you can possibly do, but we've discussed the most important bundle
