Java Reference
In-Depth Information
When to import your exports
The question on your mind probably is, “With all these benefits, shouldn't I make all
my exports substitutable?” Not necessarily. If the packages in question are somehow
coupled to private (non-exported) packages, or all packages are exported, you should
only export them. Conversely, if other bundles can reasonably expect to get the pack-
ages from a different provider, you may want to import and export them. For example,
if you're embedding and exporting common open source packages, you may want to
import them too, because other bundles may reasonably expect to get them from oth-
er providers; this is especially necessary if your other exported packages have
uses
constraints on the common packages.
Importing and exporting a package is also useful when you're using an interface-
based development approach. In interface-based programming, which is the foun-
dation of the OSGi service approach, you assume there are potentially multiple im-
plementations of well-known interfaces. You may want to package the interfaces
into their implementations to keep them self-contained. In this case, to ensure in-
teroperability, the bundles should import and export the interface packages. Be-
cause the whole point of OSGi services is to foster collaboration among bundles,
the choice between importing only or exporting and importing interface packages is
fairly common.
You do have an alternative approach: to always package your collaborative inter-
face packages into a separate bundle. By never packaging your interfaces in a bun-
dle that provides implementations, you can be sure all implementations can be
used together, because all implementations will import the shared packages. If you
follow this approach, none of your implementations will be self-contained, because
they'll all have external dependencies on the shared packages. The trade-off is de-
ciding whether you want more bundles with dependencies among them or fewer
self-contained bundles with some content overlap. It's all about balancing coupling
and cohesion.
Next, we'll look at implicit export attributes. Unlike importing exported packages,
which gives the framework resolver more flexibility when resolving imports, implicit
export attributes can be used to limit the framework's options for resolving an import.
5.1.2
Implicit export attributes
Generally speaking,
OSG
i regards the same package exported by multiple bundles as
being completely equivalent if the package versions are the same. This is beneficial
when it comes to dependency resolution, because it's possible for the framework to
satisfy an import for a given package from any available matching exporter. In
certain situations, you may not wish to have your bundle's imports satisfied by an
arbitrary bundle; instead, you may want to import from a specific bundle. For
example, perhaps you patched a bug in a common open source library, and you
don't want to risk using a nonpatched version.
OSG
i supports this through implicit
export attributes.
