-
Bug
-
Resolution: Won't Fix
-
P4
-
None
-
5.0u3
-
other
-
linux
OPERATING SYSTEM(S):
Linux
FULL JDK VERSION(S):
java version "1.5.0_03"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_03-b07)
Java HotSpot(TM) Client VM (build 1.5.0_03-b07, mixed mode)
DESCRIPTION:
The supplied testcase contains the source for a few simple classes. MyClassB
has an overloaded method myMethod with a few different argument types, one of
which is MyClassC.
MyClassA refers to MyClassB and does not use myMethod(MyClassC) at all - it
calls myMethod(char[]).
The 5.0 compiler cannot compile this class *unless* MyClassC is available:
~/sun/jdk1.5.0_03/bin/javac MyClassA.java
MyClassA.java:5: cannot access MyClassC
file MyClassC.class not found
myObjectB.myMethod(new char[] {'S', 't', 'r', 'i', 'n', 'g'});
^
1 error
The 1.4.2 compiler can (tested with jdk1.4.2_06). The difference in behaviour
comes down to how method signatures are compared during the attribution phase.
1.4.2 recognises the case of an Array type separately, and only considers that
a valid signature of a method with arguments of type Object, Cloneable or
Serializable.
The 5.0 compiler does not do this, and so needs to examine MyClassC to
determine if the two types share a subtype relationship (which clearly they
won't).
This behavioural difference seems unnecessary, and can be removed by making
the 5.0 compiler carry out the same checks as the 1.4.2 compiler in
Types.isSubTypeUnchecked().
TESTCASE:
public class MyClassA {
public static void main(String[] args) {
MyClassB myObjectB = new MyClassB();
myObjectB.myMethod(new char[] {'S', 't', 'r', 'i', 'n', 'g'});
}
}
public class MyClassB {
public void myMethod(String s) {
System.out.println(s);
}
public void myMethod(char[] c) {
System.out.println(c);
}
public void myMethod(MyClassC m) {
System.out.println(m);
}
}
public class MyClassC {
public String toString() {
return "MyClassC";
}
}
###@###.### 2005-07-01 16:24:39 GMT
Linux
FULL JDK VERSION(S):
java version "1.5.0_03"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_03-b07)
Java HotSpot(TM) Client VM (build 1.5.0_03-b07, mixed mode)
DESCRIPTION:
The supplied testcase contains the source for a few simple classes. MyClassB
has an overloaded method myMethod with a few different argument types, one of
which is MyClassC.
MyClassA refers to MyClassB and does not use myMethod(MyClassC) at all - it
calls myMethod(char[]).
The 5.0 compiler cannot compile this class *unless* MyClassC is available:
~/sun/jdk1.5.0_03/bin/javac MyClassA.java
MyClassA.java:5: cannot access MyClassC
file MyClassC.class not found
myObjectB.myMethod(new char[] {'S', 't', 'r', 'i', 'n', 'g'});
^
1 error
The 1.4.2 compiler can (tested with jdk1.4.2_06). The difference in behaviour
comes down to how method signatures are compared during the attribution phase.
1.4.2 recognises the case of an Array type separately, and only considers that
a valid signature of a method with arguments of type Object, Cloneable or
Serializable.
The 5.0 compiler does not do this, and so needs to examine MyClassC to
determine if the two types share a subtype relationship (which clearly they
won't).
This behavioural difference seems unnecessary, and can be removed by making
the 5.0 compiler carry out the same checks as the 1.4.2 compiler in
Types.isSubTypeUnchecked().
TESTCASE:
public class MyClassA {
public static void main(String[] args) {
MyClassB myObjectB = new MyClassB();
myObjectB.myMethod(new char[] {'S', 't', 'r', 'i', 'n', 'g'});
}
}
public class MyClassB {
public void myMethod(String s) {
System.out.println(s);
}
public void myMethod(char[] c) {
System.out.println(c);
}
public void myMethod(MyClassC m) {
System.out.println(m);
}
}
public class MyClassC {
public String toString() {
return "MyClassC";
}
}
###@###.### 2005-07-01 16:24:39 GMT