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.
NSME.
There are several examples of changes like this in the JDK
Annoyingly, StringBuffer.append(StringBuffer) added in JDK 1.4:
StringBuffer b1, b2;
// ...
b1.append(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);
or
b1.append(b2.toString());
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.
Correct.
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.
-J.
--
[EMAIL PROTECTED] x22801 netbeans.org ant.apache.org
http://google.com/search?q=e%5E%28pi*i%29%2B1
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
