Description
A DESCRIPTION OF THE REQUEST :
When a static initializer fails with an exception, an ExceptionInInitializerError with cause is thrown to the code initially trying to use the class—good.
But after that initial ExceptionInInitializerError, subsequent attempts to use the class throw a NoClassDefFoundError with no cause, offering no information about the original exception.
JUSTIFICATION :
In a large software system it is easy for the initial ExceptionInInitializerError to be lost somehow. Perhaps it was printed to a log, but this was rotated out of easy view—or deleted altogether. Perhaps some code caught LinkageError but “swallowed” it or logged it only at a verbose level; this is not so uncommon when using a dependency injection framework, a module system resilient to binary compatibility issues, and so on.
EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
Would prefer to have the ExceptionInInitializerError be retained and used as the cause for a subsequent NoClassDefFoundError:
Exception in thread "main" java.lang.NoClassDefFoundError: Could not initialize class Demo$CrucialComponent
at Demo.main(Demo.java:6)
Caused by: java.lang.ExceptionInInitializerError
at Demo.main(Demo.java:4)
Caused by: java.lang.IllegalStateException: Too many blattlies!
at Demo$CrucialComponent.<clinit>(Demo.java:11)
... 1 more
ACTUAL -
In JDK 7u7:
Exception in thread "main" java.lang.NoClassDefFoundError: Could not initialize class Demo$CrucialComponent
at Demo.main(Demo.java:6)
---------- BEGIN SOURCE ----------
public class Demo {
public static void main(String... args) {
try {
CrucialComponent.run();
} catch (LinkageError x) {}
CrucialComponent.run();
}
static class CrucialComponent {
static {
if (Demo.class != null) {
throw new IllegalStateException("Too many blattlies!");
}
}
static void run() {}
}
}
---------- END SOURCE ----------
CUSTOMER SUBMITTED WORKAROUND :
None known.
When a static initializer fails with an exception, an ExceptionInInitializerError with cause is thrown to the code initially trying to use the class—good.
But after that initial ExceptionInInitializerError, subsequent attempts to use the class throw a NoClassDefFoundError with no cause, offering no information about the original exception.
JUSTIFICATION :
In a large software system it is easy for the initial ExceptionInInitializerError to be lost somehow. Perhaps it was printed to a log, but this was rotated out of easy view—or deleted altogether. Perhaps some code caught LinkageError but “swallowed” it or logged it only at a verbose level; this is not so uncommon when using a dependency injection framework, a module system resilient to binary compatibility issues, and so on.
EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
Would prefer to have the ExceptionInInitializerError be retained and used as the cause for a subsequent NoClassDefFoundError:
Exception in thread "main" java.lang.NoClassDefFoundError: Could not initialize class Demo$CrucialComponent
at Demo.main(Demo.java:6)
Caused by: java.lang.ExceptionInInitializerError
at Demo.main(Demo.java:4)
Caused by: java.lang.IllegalStateException: Too many blattlies!
at Demo$CrucialComponent.<clinit>(Demo.java:11)
... 1 more
ACTUAL -
In JDK 7u7:
Exception in thread "main" java.lang.NoClassDefFoundError: Could not initialize class Demo$CrucialComponent
at Demo.main(Demo.java:6)
---------- BEGIN SOURCE ----------
public class Demo {
public static void main(String... args) {
try {
CrucialComponent.run();
} catch (LinkageError x) {}
CrucialComponent.run();
}
static class CrucialComponent {
static {
if (Demo.class != null) {
throw new IllegalStateException("Too many blattlies!");
}
}
static void run() {}
}
}
---------- END SOURCE ----------
CUSTOMER SUBMITTED WORKAROUND :
None known.