Java Reference
In-Depth Information
As you can see, dynamic imports are attempted only as a last resort. But when a
dynamically imported package is resolved and associated with the importing bundle,
it behaves just like a statically imported package. Future requests for classes in the
same package are serviced in step 2.
Avoid the Siren's song
Dynamic imports are alluring to new OSGi programmers because they provide behav-
ior similar to that in standard Java programming, where everything available on the
class path is visible to the bundle. Unfortunately, this approach isn't modular and
doesn't allow the OSGi framework to verify whether dependencies are satisfied in ad-
vance of using a bundle. As a result, dynamically importing packages should be seen
as bad practice, except for explicitly dealing with legacy SPI approaches.
You can also use dynamically imported packages in a fashion more similar to optionally
imported packages by specifying additional attributes like normal imported packages
DynamicImport-Package: javax.servlet.*; version="2.4.0"
or even
DynamicImport
-Package: javax.servlet; javax.servlet.http; version="2.4.0"
In the first case, all subpackages of
javax.servlet
of version
2.4.0
are dynamically
imported, whereas in the second only the explicitly mentioned packages are dynamically
imported. More precise declarations such as these often make less sense when you're
using dynamic imports, because the general use case is for unknown package names.
We apparently have two different ways to loosen bundle imports. Let's compare
and contrast them a little more closely.
5.2.3
Optional vs. dynamic imports
There are intended use cases for both optional and dynamic imports, but the func-
tionality they provide overlaps. To better understand each, we'll look into their simi-
larities and differences. Let's start with the similarities.
SIMILARITIES
Both are used to express dependencies on packages that may or may not be available
at execution time. Although this is the specific use case for optional imports, it's a
byproduct of dynamic imports. Either way, this has the following impact:
Optional/dynamic imports never cause a bundle to be unable to resolve.
■
Your bundle code must be prepared to catch
ClassNotFoundException
s for the
optionally/dynamically imported packages.
■
Only normally imported packages (that is, mandatory imported packages) impact
bundle dependency resolution. If a mandatory imported package can't be satisfied,
the bundle can't be resolved or used. Neither optionally nor dynamically imported
