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.

======================================================================