Java Reference
In-Depth Information
The problems with dynamic imports don't stop there. Because dynamic imports
behave like optional imports at resolution time, there's no guarantee that the package
will be available to the running bundle. This means that your library must cope with the
possibility that one, some, or
all
of its dynamic imports won't be available at runtime!
Effectively, dynamic imports are a means of circumventing the modularity of your
bundle. If used properly, they're an invaluable tool, but for the most part they're best
avoided.
12.3.4
Other problems that are more difficult to fix
The problems we've discussed so far have all had to do with modularization. Effectively,
the libraries rely on the relatively poor modularity of Java
SE
and suffer problems when
packaged as
OSG
i bundles. These sorts of problems can often (but not always) be fixed,
if only in a limited way, by careful packaging. A different class of problems are alto-
gether more unpleasant, though fortunately they're also much rarer. These are prob-
lems to do with bundle lifecycle and the structure of the framework itself.
URLS FOR CLASSPATH SCANNING
Some libraries attempt to do clever things by finding resources on the application's
classpath. Typically, they look for resources using a pattern, but crucially they don't
know the name of the resource before they find it. One example of this is if you wish
to find and run all classes that have a name ending in
Test
. To do this, the library typ-
ically looks for the root of the classpath by asking the classloader for the resource cor-
responding to
"/"
. Clearly, there are modularity problems here, but even if the library
found the correct root
URL
, there's another, bigger problem waiting.
When the framework has a root
URL
, it typically identifies it as either being a
file:
or a
jar:
URL
. After it has done this, it locates the directory or
JAR
on the filesystem, and
starts to list its contents, looking for matching files. The issue here is that
OSG
i doesn't
require the framework to have a fixed layout on the filesystem, or even be on disk at all!
The
OSG
i specification expects the framework to return
URL
s in a custom namespace.
This completely breaks any scanning performed by non-
OSG
i-aware libraries.
The only way around this sort of problem is to rewrite the library (or plug into it, if
you can) to be
OSG
i-aware when it's scanning. The only safe ways to scan bundles are
by using
findEntries()
on a
Bundle
or
listResources()
on a
BundleWiring
(the lat-
ter is only available on
OSG
i 4.3-compatible frameworks).
RESOURCE AND THREAD MANAGEMENT
If the library you're using creates its own threads or manages resources, for example
database connections, then it needs to correctly terminate or close them to prevent
erratic behavior and leaks. Given that many libraries are unaware of the
OSG
i lifecycle,
it's likely that the library won't respond to either being stopped, or uninstalled, cor-
rectly, and will probably leave orphaned threads or resources.
This sort of problem can also be demonstrated if clients are stopped, uninstalled,
or refreshed. Without proper resource management, the library can begin leaking
memory, or worse, hanging on to things related to bundles that no longer exist.
