Java Reference
In-Depth Information
org.ops4j.pax.web.pax-web-jetty
Public
Private
javax.servlet
javax.servlet.http
fancyfoods.web
Public
Private
Public
fancyfoods.web
Private
javax.naming
org.eclipse.osgi
Figure 2.6
The class space of the
fancyfoods.web
bundle. It doesn't have any public packages.
To confirm which bundle exports the
javax.servlet
package, type
packages
javax.servlet
in your OSGi console, or
bundle
fancyfoods.web
to see where all of the packages used by
fancyfoods.web
come from.
EXPLICIT DEPENDENCIES
Being a bundle has a second implication, which is that all the packages required by
SayHello
must be explicitly imported in the manifest. If you're just getting used to
OSG
i, this can seem like an unnecessary—and annoying—extra step.
Let's step back and think about how Java handles package imports for classes. If
you were writing a Java class, you'd always import the packages you were using, rather
than expecting the compiler to choose a class with the right name from a random
package. Some class names are unique, and you'd probably end up with the right one,
but other class names are not at all unique. Imagine how horrible it would be if your
class could end up running against any class called
Constants
, for example.
You might also end up with the opposite problem—instead of a class name that was
too common, you could be trying to use a class that didn't exist at all. If the package you
needed didn't exist at all, you'd expect an error at compile time. You certainly wouldn't
want the compilation to limp along, claim success, and produce a class that half-worked.
