Mastering modularity - OSGi in Action - page 42

As you can see, the internal bundle class path concept is powerful and flexible when it
comes to defining the contents and internal search order of bundles; refer to the side-
bar “Bundle class path flexibility” for some examples of when this flexibility is useful.
Next, you'll learn how to expose internal code for sharing with other bundles.
Bundle class path flexibility
You may wonder why you'd want to package classes in different directories or embed
JAR files in the bundle JAR file. First, the bundle class path mechanism doesn't apply
only to classes, but also to resources. A common use case is to place images in an
image/ directory to make it explicit in the JAR file where certain content can be found.
Also, in web applications, nested JAR files are embedded in the JAR file under the
WEB-INF/lib/ directory and classes can be placed in the WEB-INF/classes/ directory.
In other situations, you may have a legacy or proprietary JAR file that you can't change.
By embedding the JAR file into your bundle and adding bundle metadata, you can use
it without changing the original JAR. It may also be convenient to embed a JAR file
when you want your bundle to have a private copy of some library; this is especially
useful when you want to avoid sharing static library members with other bundles.
Embedding JAR files isn't strictly necessary, because you can also unpack a standard
JAR file into your bundle to achieve the same effect. As an aside, you can also see a
performance improvement by not embedding JAR files, because OSGi framework im-
plementations must extract the embedded JAR files to access them.
EXPORTING INTERNAL CODE
Bundle-ClassPath affects the visibility of classes in a bundle, but how do you share
classes among bundles? The first stage is to export the packages you wish to share with
others.
Externally useful classes are those composing the public API of the code contained
in the JAR file, whereas non-useful classes form the implementation details. Standard
JAR files don't provide any mechanism to differentiate externally useful classes from
non-useful ones, but OSG i does. A standard JAR file exposes everything relative to the
root by default, but an OSG i bundle exposes nothing by default. A bundle must use
the Export-Package manifest header to explicitly expose internal classes it wishes to
share with other bundles.
EXPORT-PACKAGE A comma-separated list of internal bundle packages to
expose for sharing with other bundles.
Instead of exposing individual classes, OSG i defines sharing among bundles at the pack-
age level. Although this makes the task of exporting code a little simpler, it can still be
a major undertaking for large projects; we'll discuss some tools to simplify this in appen-
dix A. When you include a package in an Export-Package declaration, every public class
contained in the package is exposed to other bundles. A simple example for the paint