Java Reference
In-Depth Information
pick up the reference to the
org.gjt.sp.jedit.print
package? Remember that bnd
works primarily on byte code, not source code; it won't pick up packages referenced
in scripts, arbitrary strings, or runtime configuration files. The only reference to this
package was in a BeanShell script, which wasn't analyzed by the bnd tool.
You now have all the answers as to why the script failed, but how should you solve
the problem? Bnd supports adding custom analyzers to process additional content, so
you could write your own BeanShell analyzer for bnd. But what if writing such an ana-
lyzer is outside your expertise? Can you instead fix the class-loading problem at execu-
tion time? There are two approaches to solving this type of class-loading issue:
Attempt to use a different class loader to load the class.
■
Add the necessary imports to the bundle doing the loading.
■
The first approach is only possible when the library provides some way of passing in
the class loader or when it uses the Thread Context Class Loader (
TCCL
) to load
classes. (You can read more about the
TCCL
in chapter 8.) The BeanShell library does
provide a method to set the class loader, but jEdit is already using it to pass in the spe-
cial class loader that provides access to all currently installed jEdit plugins. Rather
than mess around with jEdit's internal
JARClassLoader
code and potentially break
the jEdit plugin framework, you'll take the second approach and add the missing
imports to the main bundle. This has the least impact on existing jEdit code—all
you're doing is updating the
OSG
i part of the manifest.
You know that you need to import the
org.gjt.sp.jedit.print
package, but
what else might you need? To make absolutely sure, you'd have to run through a
range of tests exercising the whole of the jEdit
GUI
. Although this testing could be
automated to save time, let's instead try the suggestion from the end of section 6.1.3
and allow the main jEdit bundle to import any package on demand:
DynamicImport-Package: *
Add this to the jedit-main.bnd instruction file, and rebuild one more time. You can
now open the print dialog box without getting the error message. The application will
also continue to work even if you use a more restrictive dynamic import, such as
DynamicImport-Package: org.gjt.sp.*
Why does this work? Well, rather than say up front what you import, you leave it open
to whatever load requests come through the main bundle class loader. As long as
another bundle exports the package, and it matches the given wildcard, you'll be able
to see it. But is this the right solution? Merging the main and engine bundles back
together would solve the BeanShell problem without the need for dynamic imports. You
already know these bundles are tightly coupled; keeping them apart is causing you fur-
ther trouble. This is a good example of when introducing more bundles doesn't make
sense.
OSG
i isn't a golden hammer, and it won't magically make code more modular.
In short, if you're getting class-loading errors or are sharing lots of packages between
bundles, that could be a sign that you should start merging them back together. You may
