Java Reference
In-Depth Information
package a;
public class A {}
package a;
public class A {}
package a;
public class A {}
package a;
class B {}
package a;
class B {}
package a;
class B {}
package a;
class C {}
package a;
class C {}
package a;
class C {}
A can see B and C
B can see A and C
C can see A and B
A
can't see B or C
B can see A and C
C can see A and B
A can see B
but not
C
B can see A
but not
C
C can see A
but not
B
Figure 8.10
Split packages and package-private visibility
Most
ClassNotFoundException
s are easily solved by checking bundle manifests and
configuration files. The hardest problems involve third-party custom class loaders; you
inevitably need access to the class loader's source code to determine why it couldn't
see a particular class, as well as have the patience to unravel the exception stack.
That's
ClassNotFoundException
, but how is
NoClassDefFoundError
any different?
NOCLASSDEFFOUNDERROR
First, this is an error rather than an exception, which means applications are discour-
aged from catching it. Second, it means the initial class that started the current load
cycle
was
found, but the class loader wasn't able to finish loading it because a class it
depends on was missing. This can happen when a class is compiled against a depen-
dent
API
, but the resulting bundle neither contains nor imports that package.
Continuing with the exceptional example, type the following:
$
./chapter08/classloading/PICK_EXAMPLE 2
This time, the extender metadata in the spoke bundle is correct, but the bundle
doesn't import the
org.foo.hub.spi
package containing the
Spoke
interface. The
runtime begins to load the spoke implementation but can't find the named interface
when defining the class:
java.lang.NoClassDefFoundError: org/foo/hub/spi/Spoke
...
Caused by: java.lang.ClassNotFoundException: org.foo.hub.spi.Spoke
Debugging a
NoClassDefFoundError
involves tracing back through the dependencies
of the class being loaded to find the missing link (or links). Although the cause in this
example is clear, developers often get side-tracked by assuming the initial class is at
fault. The real culprit may be hidden down at the bottom of the stack as the original
