I see differences between platforms about when Class.forName () throws a ClassNotFoundException and when it throws a NoClassDefFoundError. Is this behavior defined in a certain way, or have I come across an error?
Consider the following code (which is a stand-alone java file in the default package):
public class DLExceptionType {
private static void printFindError(String name) {
System.out.print(name + ": ");
try {
Class.forName(name);
System.out.println("** no error **");
} catch (Throwable e) {
System.out.println(e);
}
}
public static void main(String[] args) {
printFindError("DLExceptionType");
printFindError("dLExceptionType");
}
}
The code displays the expected result on Linux:
[eos18:~]$ java -version DLExceptionType
java version "1.6.0_26"
Java(TM) SE Runtime Environment (build 1.6.0_26-b03)
Java HotSpot(TM) 64-Bit Server VM (build 20.1-b02, mixed mode)
[eos18:~]$ java DLExceptionType
DLExceptionType: ** no error **
dLExceptionType: java.lang.ClassNotFoundException: dLExceptionType
It produces a different but understandable output on Windows:
java version "1.7.0_01"
Java(TM) SE Runtime Environment (build 1.7.0_01-b08)
Java HotSpot(TM) Client VM (build 21.1-b02, mixed mode, sharing)
Y:\Temp>java DLExceptionType
DLExceptionType: ** no error **
dLExceptionType: java.lang.NoClassDefFoundError: dLExceptionType (wrong name: DLExceptionType)
Windows exit makes sense: since the file system is not case sensitive, the JVM loads the dLExceptionType.class file, but this file contains a class with a different name: DLExceptionType
However, when I run the code on a Mac (with a case-sensitive file system and a newer JVM than Linux), I get the same result as Windows:
$ java -version
java version "1.6.0_29"
Java(TM) SE Runtime Environment (build 1.6.0_29-b11-402-10M3527)
Java HotSpot(TM) 64-Bit Server VM (build 20.4-b02-402, mixed mode)
$ java DLExceptionType
DLExceptionType: ** no error **
dLExceptionType: java.lang.NoClassDefFoundError: dLExceptionType (wrong name: DLExceptionType)