It's possible to export the same package more than once with different attri-
butes, which is sometimes helpful if a bundle wishes to masquerade as more
than one version of a package.
The framework ignores optionally imported packages if no exporters are pres-
ent when the importing bundle is resolved.
The framework only attempts to resolve dynamically imported packages when
the importing bundle tries to use a class in the dynamically imported package.
Repeated attempts to use a class in the dynamically imported package will result
in repeated attempts to resolve the package until successful.
It's possible to require a bundle, rather than importing specific packages, which
wires you to everything the target bundle exports. This is typically useful when
aggregating split packages.
Bundle fragments support splitting a bundle into multiple optional JAR files,
which is helpful in such situations as localization.
Bundles with dependencies on specific Java platforms can declare these depen-
dencies with required execution environments.
Bundles can include native libraries to integrate platform-specific functionality.
Most of these mechanisms are intended for specific use cases and shouldn't be over-
used to avoid less modular solutions.
We've now covered all the major functionality of OSG i specification, which closes
out this part of the topic. In the next section, we'll look into more practical matters
that crop up while trying to use and build applications on top of OSG i technology.