Java Reference
In-Depth Information
clients, your job would be complete. But there's a hitch: a class from the Collections
package is indirectly exposed to BeanUtils clients via a return type on some depre-
cated methods. What can you do? You need to find a way to guarantee that the Bean-
Utils bundle uses the same Commons Collections provider as its clients. The simplest
solution would be to make this dependency explicit by importing
org.apache.
commons.collections
into the BeanUtils bundle, but then your bundle wouldn't
resolve unless the Commons Collections bundle was also installed. Perhaps you could
you use an
optional
import instead:
Import-Package: org.apache.commons.collections;resolution:=optional
Now, if the full package is available, you'll import it; but if it's not available, you can still
use your internal private copy. Will this work? It's better, but it still isn't entirely accurate.
Unfortunately, the only correct way to resolve this situation is to refactor the
BeanUtils bundle to not contain the partial private copy of
org.apache.commons.
collections
. See the sidebar “Revisiting
uses
constraints” if you want more details
as to why an optional import won't work.
Revisiting
uses
constraints
We hypothesized about modifying the example BeanUtils bundle to optionally import
org.apache.commons.collections
. The idea was that your bundle would import it
if an exporter was available, but would use its private copy if not. This doesn't work,
but why not? It's all about
uses
constraints, as discussed in section 2.7.2.
As we mentioned, BeanUtils exposes a type from the Collections package in a return
type of a method in its exported types; this is a
uses
constraint by definition. To deal
with this situation, you must express it somehow. Let's assume you follow the op-
tional import case and try to model the
uses
constraint correctly, like this:
Export-Package:
org.apache.commons.beanutils;
uses:="org.apache.commons.collections",
org.apache.commons.beanutils.converters,
org.apache.commons.beanutils.locale;
uses:="org.apache.commons.collections",
org.apache.commons.beanutils.locale.converters
Import-Package: org.apache.commons.collections;resolution:=optional
This may work in some situations; for example, it would work if you deployed your
BeanUtils bundle, another bundle importing BeanUtils and Collections, and a bundle
exporting the Collections package. In this case, all the bundles would be wired up to
each other, and everyone would be using the correct version of the Collections pack-
ages. Great!
But what would happen if the BeanUtils bundle was installed and resolved by itself
first? In that case, it wouldn't import the Collections package (because there isn't
one) and would use its private partial copy instead. Now, if the other bundles were
installed and resolved, you'd end up with the wiring depicted here:
