Name: vrR10176 Date: 07/16/2002
The API spec for method ClassLoader.defineClass(String name, byte b,
int off, int len, ProtectionDomain protectionDomain) reads:
"If the name parameter is not null, it must be equal to the name of the class
specified by the byte array b, otherwise a ClassFormatError is raised."
But the API spec for ClassFormatError reads:
"Thrown when the Java Virtual Machine attempts to read a class file and determines
that the file is malformed or otherwise cannot be interpreted as a class file."
So if byte array b describes valid class file, the exception ClassFormatError
looks like inappropriate in this case. More consistent exception in this case
is NoClassDefFoundError. It also conforms to JVMS-2 specification:
"5.3.5 Deriving a Class from a class File Representation
2.Otherwise, the Java virtual machine attempts to parse the purported representation.
However, the purported representation may not in fact be a valid representation of C.
This phase of loading must detect the following errors:
-If the purported representation is not in class file format, loading throws an instance of ClassFormatError.
-Otherwise, if the purported representation is not of a supported major or minor version, loading throws an
instance of UnsupportedClassVersionError.
-Otherwise, if the purported representation does not actually represent a class named N, loading throws an
instance of NoClassDefFoundError or an instance of one of its subclasses."
Moreover JDKs (jdk1.4.0-b92, jdk1.4.1-b15) throw NoClassDefFoundError if name is not equal
to the name of the class specified by the byte array b.
Likely ClassFormatError should be replaced with NoClassDefFoundError in mentioned JavaDoc assertion.