Java Reference
In-Depth Information
How is it possible, you ask? The trick is that the bundle doesn't contain two separate
sets of classes for the two exported packages. The bundle is masquerading the same
set of classes as different packages. Why would it do this? Expounding on the previous
snippet, perhaps you have unmodifiable third-party bundles with explicit dependen-
cies on
javax.servlet
version
2.3.0
in your application. Because version
2.4.0
is
backward compatible with version
2.3.0
, you can use duplicate exports to allow your
bundle to stake a backward compatibility claim. In the end, all bundles requiring
either version of
javax.servlet
can resolve, but they'll all use the same set of classes
at execution time, as shown in figure 5.8.
As with export filtering, this is another mechanism to manage your
API
s. You can
take this further and combine it with some of the other mechanisms you've learned
about in this section for additional
API
management techniques. For example, you
generally don't want to expose your bundle's implementation details to everyone, but
sometimes you want to expose implementation details to select bundles; this is similar
to the friend concept in C++. A friend is allowed to see implementation details, but
nonfriends aren't. To achieve something like this in
OSG
i, you need to combine man-
datory export attributes, export filtering, and duplicate exports.
To illustrate, let's return to the example from export filtering:
Export-Package: org.foo.service; version="1.0.0"; exclude:="Util"
In this example, you excluded the
Util
class, because it was an implementation detail.
This is the exported package your nonfriends should use. For friends, you need to
export the package without filtering:
Export-Package: org.foo.service; version="1.0.0"; exclude:="Util",
org.foo.service; version="1.0.0"
Now you have one export hiding the
Util
class and one exposing it. How do you con-
trol who gets access to what? That's right: mandatory export attributes. The following
complete export metadata gives you what you need:
Export-Package: org.foo.service; version="1.0.0"; exclude:="Util",
org.foo.service; version="1.0.0"; friend="true"; mandatory:="friend"
Only bundles that explicitly import your package with the
friend
attribute and
matching value see the
Util
class. Clearly, this isn't a strong sense of friendship,
because any bundle can specify the
friend
attribute; but at least it requires an opt-in
export
javax.servlet
version="2.3.0"
import
javax.servlet
version="[2.3.0, 2.4.0)"
B
A
One set of classes
for javax.servlet
.class
.class
.class
Figure 5.8
A bundle can export the
same package multiple times, but this
is only a form of masquerading. Only
one set of classes exists for the
package in the bundle.
C
import
javax.servlet
version="[2.4.0, 2.5.0)"
export
javax.servlet
version="2.4.0"
