Java Reference
In-Depth Information
Depending on packages, not bundles
Importing packages seems fairly normal for most Java programmers, because you im-
port the classes and packages you use in the source files. But the
import
state-
ments in the source files are for managing namespaces, not dependencies. OSGi's
choice of using package-level granularity for expressing dependencies among bun-
dles is novel, if not controversial, for Java-based module-oriented technologies. Other
approaches typically adopt module-level dependencies, meaning dependencies are
expressed in terms of one module depending on another. The OSGi choice of pack-
age-level dependencies has created some debate about which approach is better.
The main criticisms leveled against package-level dependencies is that they're too
complicated or fine-grained. Some people believe it's easier for developers to think
in terms of requiring a whole JAR file rather than individual packages. This argument
doesn't hold water, because a Java developer using any given technology must know
something about its package naming. For example, if you know enough to realize you
want to use the
Servlet
class in the first place, you probably have some idea about
which package it's in, too.
Package-level dependencies are more fine-grained, which does result in more meta-
data. For example, if a bundle exports 10 packages, only 1 module-level dependen-
cy is needed to express a dependency on all of them, whereas package-level
dependencies require 10. But bundles rarely depend on all exported packages of a
given bundle, and this is more of a condemnation of tooling support. Remember
how much of a nuisance it was to maintain import declarations before IDEs started
doing it for you? This is starting to change for bundles, too; in appendix A, we de-
scribe tools for generating bundle metadata. Let's look at some of the benefits of
package-level dependencies.
The difference between module- and package-level dependencies is one of
who
ver-
sus
what
. Module-level dependencies express which specific module you depend on
(who), whereas package-level dependencies express which specific packages you de-
pend on (what). Module-level dependencies are brittle, because they can only be sat-
isfied by a specific bundle even if another bundle offers the same packages. Some
people argue that this isn't an issue, because they want the specific bundle they've
tested against, or because the packages are implementation packages and won't be
provided by another bundle. Although these arguments are reasonable, they usually
break down over time.
For example, if your bundle grows too large over time, you may wish to refactor it
by splitting its various exported packages into multiple bundles. If you use module-
level dependencies, such a refactoring will break existing clients, which tends to be
a real bummer when the clients are from third parties and you can't easily change
them. This issue goes away when you use package-level dependencies. Also,
a bundle doesn't usually depend on
everything
in another bundle, only a
subset
. As
a result, module-level dependencies are too broad and cause transitive fanout.
You end up needing to deploy a lot of extra bundles you don't use, just to satisfy
all the dependencies.
