Java Reference
In-Depth Information
metadata for getting started creating bundles; we'll cover additional modularity issues
in chapter 5. Next, you'll put all the metadata in place for the paint program and then
step back to review the current design. Before moving on, if you're wondering if it's
possible to have a
JAR
file that is both a bundle and an ordinary
JAR
file, see the side-
bar “Is a bundle a
JAR
file or a
JAR
file a bundle?”
Is a bundle a JAR file or a JAR file a bundle?
Maybe you're interested in adding OSGi metadata to your existing JAR files or you want
to create bundles from scratch, but you'd still like to use them in non-OSGi situations
too. We've said before that a bundle is just a JAR file with additional module-related
metadata in its manifest file, but how accurate is this statement? Does it mean you
can use any OSGi bundle as a standard JAR file? What about using a standard JAR
file as a bundle? Let's answer the second question first, because it's easier.
A standard JAR file can be installed into an OSGi framework unchanged. Unfortunate-
ly, it doesn't do anything useful. Why? The main reason is that a standard JAR file
doesn't expose any of its content; in OSGi terms, it doesn't export any packages. The
default
Bundle-ClassPath
for a JAR file is
.
, but the default for
Export-Package
is
nothing. So even though a standard JAR file is a bundle, it isn't a useful bundle. At a
minimum, you need to add an
Export-Package
declaration to its manifest file to ex-
plicitly expose some (or all) of its internal content.
What about bundle JAR files? Can they be used as a standard JAR file outside of an
OSGi environment? The answer is, it depends. It's possible to create bundles that
function equally well in or out of an OSGi environment, but not all bundles can be
used as standard JAR files. It comes down to which features of OSGi your bundle us-
es. Of the metadata features you've learned about so far, only one can cause issues:
Bundle-ClassPath
. Recall that the internal bundle class path is a comma-separated
list of locations inside the bundle JAR file and may contain
■
A . representing the root of the bundle JAR file
■
A relative path to an embedded JAR file
■
A relative path to an embedded directory
Only bundles with a class path entry of
.
can be used as standard JAR files. Why?
The OSGi notion of
.
on the bundle class path is equivalent to standard JAR file class
searching, which is to search from the root of the JAR file as if all relative directories
are package names. If a bundle specifies an embedded JAR file or directory, it re-
quires special handling that's available only in an OSGi environment. Luckily, it isn't
too difficult to avoid using embedded JAR files and directories.
It's a good idea to try to keep your bundle JAR files compatible with standard JAR
files if you can, but it's still best to use them in an OSGi environment. Without
OSGi, you lose dependency checking, consistency checking, and boundary enforce-
ment, not to mention all the cool lifecycle and service stuff we'll discuss in the
coming chapters.
