ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jesse Glick <>
Subject Re: Ant 1.7 release
Date Sat, 10 Jun 2006 18:44:44 GMT
Stefan Bodewig wrote:
> Say there is a method 
>      void doSomething(Object o);
> in a class inside the Java class library of JDK 1.3 and a new overload
>      void doSomething(String s);
> was added in JDK 1.4.  Any call to doSomething("") compiled on JDK 1.4
> and above will pick the String signature and fail with a
> NoSuchMethodError (or IncompatibleClassChange, not sure) when run on
> JDK 1.3.


> There are several examples of changes like this in the JDK

Annoyingly, StringBuffer.append(StringBuffer) added in JDK 1.4:

StringBuffer b1, b2;
// ...

when compiled against JDK 1.4's rt.jar will yield code which does not 
run on JDK 1.3 - even though the same code compiles on JDK 1.3 and runs 
fine on either JDK! You need to write

b1.append((Object) b2);



to ensure that the code can be safely compiled and run on either JDK.

> so you can't be sure it works just bbbe setting the correct target.


> Java 5 adds a completely new sort of problems with APIs retrofitted to
> support generics.  Since Comparable is now Comparable<T> the
> BigInteger class used to have a method
>     int compareTo(Object)
> and now has a 
>     int compareTo(BigInteger)
> and no Object signature alternative.

Not true. Check javap; both signatures exist in the bytecode. javac 
-source 1.5 automatically creates the cT(Object) overload which 
delegates to cT(BI) after a cast. This is necessary for compatibility 
with 1.4-based client code.


--  x22801*i%29%2B1

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message