Delving deeper into modularity - OSGi in Action - page 155

In this chapter, we'll investigate more aspects of OSG i's module layer. We'll look
into simple features, such as making imported packages a little more flexible, and into
more complicated ones, such as splitting Java packages across multiple bundles or
breaking a single bundle into pieces. You probably won't need to use most of the fea-
tures described in this chapter as often as the preceding ones; if you do, you should
review your design, because it may not be sufficiently modular. With that said, it's
worthwhile to be aware of these advanced features of the OSG i module layer and the
circumstances under which they're useful. To assist in this endeavor, we'll introduce
use cases and examples to help you understand when and how to apply them.
This chapter isn't strictly necessary for understanding subsequent chapters, so feel
free to postpone reading it until later. Otherwise, let's dig in.

5.1 Managing your exports

From what you've learned so far, exporting a package from a bundle is fairly simple:
include it in the Export-Package header, and potentially include some attributes.
This doesn't cover all the details of exporting packages. In the following subsections,
we'll discuss other aspects, like importing exported packages, implicit attributes, man-
datory attributes, class filtering, and duplicate exports.

5.1.1 Importing your exports

In chapter 2, you learned how Export-Package exposes internal bundle classes and
how Import-Package makes external classes visible to internal bundle classes. This
seems to be a nice division of labor between the two. You may even assume the two are
mutually exclusive. In other words, you may assume a bundle exporting a given pack-
age can't import it also and vice versa. In many module systems, this would be a rea-
sonable assumption, but for OSG i it's incorrect. A bundle importing a package it
exports is a special case in OSG i, but what exactly does it mean? The answer to this
question is both philosophical and technical.
The original vision of the OSG i service platform was to create a lightweight execu-
tion environment where dynamically downloaded bundles collaborate. In an effort to
meet the “lightweight” aspect of this vision, these bundles collaborated by sharing
direct references to service objects. Using direct references means that bundles collab-
orate via normal method calls, which is lightweight. As a byproduct of using direct ref-
erences, bundles must share the Java class associated with shared service objects. As
you've learned, OSG i has code sharing covered in spades with Export-Package and
Import-Package . Still, there's an issue lurking here, so let's examine a collaboration
scenario more closely.
Imagine that bundle A wants to use an instance of class javax.servlet.Servlet
from bundle B. As you now understand, in their respective metadata, bundle A will
import package javax.servlet , and bundle B will export it. Makes sense. Now imag-
ine that bundle C also wants to share an instance of class javax.servlet.Servlet
with bundle A. It has two choices at this point: