Lew wrote:
Mike Schilling wrote:
I have some Java code that analyzes Java code using reflection. It
loads classes using ClassLoader.loadClass() (catching the
ClassNotFoundException if they're missing) and then uses reflection
to gather data about them. I started up what should have been a
long run before I left work, and later this evening remoted in to
find that it had died almost immediately.
Why? It appears that trying to load class AaaBbb but finding class
Aaabbb whose name differs only in case (quite easy to do on a
case-insensitive file system), instead of throwing a
ClassNotFoundException, throws a NoClassDefFoundError (that's
right,
Error.) This was not caught, and caused the program to exit. This
is not documented behavior. It's not hard to fix (catch Throwable
instead of the expected ClassNotFoundException), but the result is
that something which should have completd overnight might or might
not be done by tomorrow morning.
NoClassDefFoundError is the standard response by the JVM when the
desired class, in this case AaaBbb, is not present at run time.
As documented, it's when a class referenced via normal Java processing
(e.g. running "new" on it) can't be found at run time. Here my code
was explicitly calling Classloader.loadClass();
The problem is that the reflective code didn't catch that the class
was missing. So it passed on to the JVM the request to go ahead and
load the class. That's why it was an Error, not an Exception. It's
an Error when the situation is so tangled that the JVM cannot fix
it.
It's not really tangled. The Classloader opens the file and find that
it contains the wrong class; really not much more complex than not
being able to open the file.
Thus you experienced the correct behavior.
In this case I infer that you were running under Windows, and the OS
lied to the JVM about the availability of the class, precluding the
Exception and forcing the Error.
I'm sure that the implementation is something like that. Still, it
wouldn't have been hard for loadClass() to catch the Error and throw
an Exception; that's the fix I put in. And it would result in the
bloody method behaving as documented.