-
Bug
-
Resolution: Fixed
-
P3
-
1.1.1, 1.1.2
-
1.1.4
-
x86
-
generic, windows_nt
-
Not verified
I thought that an invariant of a successful Class.forName() was
Class.forName(X).getName().equals(X);
We rarely (before finding this bug to workaround) ever check the
name of a Class returned by Class.forName().
On Windows 95 (at least, haven't verified on NT)
If there is a file XyZ.class containing class XyZ, then I would
have expected Class.forName("xyz") or Class.forName("XYZ") to fail,
as they do on Solaris.
However, this is not the case. Any capitalization of the class name will
return the same result, class XyZ.
First, this is a compatibility issue. Second, I thought Java was a case-sensitive language.
Simplest test code:
public class CfN {
public static void main(String[] args) throws Throwable {
Class c = Class.forName(args[0]);
System.err.println(c);
System.err.println("correct name? "+(c.getName().equals(args[0])));
}
}
Class.forName(X).getName().equals(X);
We rarely (before finding this bug to workaround) ever check the
name of a Class returned by Class.forName().
On Windows 95 (at least, haven't verified on NT)
If there is a file XyZ.class containing class XyZ, then I would
have expected Class.forName("xyz") or Class.forName("XYZ") to fail,
as they do on Solaris.
However, this is not the case. Any capitalization of the class name will
return the same result, class XyZ.
First, this is a compatibility issue. Second, I thought Java was a case-sensitive language.
Simplest test code:
public class CfN {
public static void main(String[] args) throws Throwable {
Class c = Class.forName(args[0]);
System.err.println(c);
System.err.println("correct name? "+(c.getName().equals(args[0])));
}
}
- duplicates
-
JDK-4046684 The jdb dump command ignores case distinctions.
- Closed