Java Reference
In-Depth Information
(continued)
import
org.apache.commons.collections
import
org.apache.commons.beanutils
import
org.apache.collections
resolution:=optional
Collections
Importing
bundle
BeanUtils
export
org.apache.commons.beanutils
export
org.apache.commons.collections
A
uses
constraint on an optionally imported package is ignored if the optionally imported
package isn't wired to an exporter.
This means the BeanUtils bundle is using its own private copy of the Collections
types, whereas the importing bundle is using its imported collections types, so it will
receive a
ClassCastException
if it uses any methods from BeanUtils that expose
Collections types. In the end, there's no way to have a private copy of a package if
its types are exposed via exported packages. As we've concluded already, you must
refactor your bundle to export preferably the whole package or to import the package.
A surprising number of third-party libraries include partial packages. Some want to
reuse code from another large library but don't want to bloat their own
JAR
file. Some
prefer to ship a single self-contained
JAR
file that clients can add to their class path
without worrying about conflicting dependencies. Some libraries even use tools such
as Jar Jar Links (
http://code.google.com/p/jarjar/
)
to repackage internal dependen-
cies under different namespaces to avoid potential conflicts. This leads to multiple
copies of the same class all over the place, because Java doesn't provide modularity
out of the box! Renamed packages also make debugging harder and confuse develop-
ers.
OSG
i removes the need for renaming and helps you safely share packages while
still allowing you to hide and embed implementation details.
A t t h i s p o i n t , y o u m a y d e c i d e i t 's a g o o d t i m e t o r e f a c t o r t h e
API
to make it more mod-
ular. Separating interfaces from their implementations can avoid the need for partial (or
so-called
split
) packages. This helps you reduce the set of packages you need to export
and make your bundle more manageable. Although this may not be an option for third-
party libraries, it's often worth taking time to contact the original developers to explain
the situation. This happened a few years ago with the
SLF4J
project, which refactored its
API
to great effect (
www.slf4j.org/pipermail/dev/2007-February/000750.html
)
. You
should also be careful to avoid accidentally leaking implementation types via method sig-
natures. As you saw with the BeanUtils example, the more internal details are exposed
through your
API
, the harder it is to modularize your code.
VERSIONING EXPOR TED PACKAGES
After you have your list of exported packages, you should consider versioning them.
Which version should you use? The common choice is to use the bundle version,
