Learning lifecycle - OSGi in Action - page 115

■ If they're from an exported package, their visibility depends on whether other
bundles are using them:
- If no other bundles are using the exported packages, the new classes become
available immediately. The old versions of the classes are no longer needed.
- If any other bundles are using the exported packages, the new classes don't
become available immediately, because the old version is still required. In
this case, the new classes aren't made available until the PackageAdmin.
refreshPackages() method is called.
There is yet another nuance. In chapter 5, you'll learn that bundles can also import
the same packages they export. If a bundle imports a package it exports, and the
imported package from the updated bundle matches the exported package from the
old version, the updated bundle's import is wired to the old exported packages. This
may work out well in some cases—when you're fixing a bug in a private package, for
example. But it can potentially lead to odd situations, because the updated bundle is
using new versions of private classes alongside old versions of exported classes. If you
need to avoid this situation, you should specify version ranges when your bundle
imports its own packages.
If the updated bundle imports its own package, but the import doesn't match the
old version of the exported package, you have a different situation. It's similar to the
case where the bundle only exports the package. In this case, the new classes from the
exported packages become available immediately to the updated exporting bundle
and for future resolves of other bundles, but not to existing importer bundles, which
continue to see the old version. This situation generally requires Package-
Admin.refreshPackages() to bring the bundles back to a useful state.
You can avoid some of these issues through interface-based programming and
bundle partitioning. For example, if you can separate shared API s (the API s through
which bundles interact) into interfaces, and you place those interfaces into a
separate set of packages contained in a separate bundle, you can sometimes simplify
this situation. In such a setup, both the client bundles and the bundles implement-
ing the interfaces have dependencies on the shared API bundle, but not on each
other. In other words, you limit the coupling between clients and the providers of
the functionality.

3.6 Summary

In this chapter, you've seen that whether your desire is to deploy the bundles needed
to execute your application or to create a sophisticated auto-adaptive system, the life-
cycle layer provides everything you need. Let's review what you've learned:

A bundle can only be used by installing it into a running instance of the OSG i
framework.

■

The lifecycle layer API is composed of three main interfaces: BundleActivator ,
BundleContext , and Bundle .

■