M
Mike Schilling
Consider the following simple class:
class Compare
{
public int meth(String s, Object o)
{
return s.compareTo(o);
}
}
This compiles just fine under JDK 1.4, where Comparable contains the
signature compareTo(Object o); But in JDK 1.6, where Comparable<T>
contains compareTo(T o), compiling it gives
% c:/jdk1.6/bin/javac -g Compare.java
Compare.java:5: compareTo(java.lang.String) in java.lang.String cannot
be applied to (java.lang.Object)
return s.compareTo(o);
^
1 error
I can see why it works this way, but it still surprised me; I hadn't
thought that generics would cause existing code not to compile (as
opposed to generating tons of warnings, which I'm used to.)
Obviously, String (and the other system classes that now implement
Comparable<T>) could still contain compareTo(Object) for
compatibility.
class Compare
{
public int meth(String s, Object o)
{
return s.compareTo(o);
}
}
This compiles just fine under JDK 1.4, where Comparable contains the
signature compareTo(Object o); But in JDK 1.6, where Comparable<T>
contains compareTo(T o), compiling it gives
% c:/jdk1.6/bin/javac -g Compare.java
Compare.java:5: compareTo(java.lang.String) in java.lang.String cannot
be applied to (java.lang.Object)
return s.compareTo(o);
^
1 error
I can see why it works this way, but it still surprised me; I hadn't
thought that generics would cause existing code not to compile (as
opposed to generating tons of warnings, which I'm used to.)
Obviously, String (and the other system classes that now implement
Comparable<T>) could still contain compareTo(Object) for
compatibility.