Delving deeper into modularity - OSGi in Action - page 164

strategy for using implementation details, signaling that the importer is willing to live
with the consequences of potential breaking changes in the future.
Best practice dictates avoiding the friendship concept, because it weakens modular-
ity. If an API is valuable enough to export, you should consider making it a public API .
In this section, we've covered additional capabilities that OSG i provides for export-
ing packages to help you deal with various uncommon use cases. Likewise, OSG i pro-
vides some additional capabilities for importing packages. In the next section, you'll
learn how to make importing packages a little more flexible, which again can provide
some wiggle room when you're trying to get legacy Java applications to work in an
OSG i environment.

5.2 Loosening your imports

Explicitly declared imports are great, because explicit requirements allow you to more
easily reuse code and automate dependency resolution. This gives you the benefit of
being able to detect misconfigurations early rather than receiving various class-load-
ing and class-cast exceptions at execution time. On the other hand, explicitly declared
imports are somewhat constraining, because the framework uses them to strictly con-
trol whether your code can be used; if an imported package can't be satisfied, the
framework doesn't allow the associated bundle to transition into the RESOLVED state.
Additionally, to import a package, you must know the name of a package in advance,
but this isn't always possible.
What can you do in these situations? The OSG i framework provides two different
mechanisms for dealing with such situations: optional and dynamic imports. Let's
look into how each of these can help, as well as compare and contrast them.

5.2.1 Optional imports

Sometimes a given package imported by a bundle isn't strictly necessary for it to func-
tion properly. Consider an imported package for a nonfunctional purpose, like log-
ging. The code in a given bundle may have been programmed to function properly
regardless of whether a logging facility is available. To express this, OSG i provides the
resolution directive for the Import-Package manifest header to mark imported
packages as optional.

RESOLUTION DIRECTIVE The resolution import package directive can have a
value of mandatory or optional to indicate whether the imported package is
required to successfully resolve the bundle.

Consider the following metadata snippet:

Import-Package: javax.servlet; version="2.4.0",
org.osgi.service.log; version="1.3.0"; resolution:="optional"
This import statement declares dependencies on two packages, javax.servlet and
org.osgi.service.log . The dependency on the logging package is optional, as indi-
cated by the use of the resolution directive with the optional value. This means the