-
Bug
-
Resolution: Fixed
-
P2
-
5.0
Issue | Fix Version | Assignee | Priority | Status | Resolution | Resolved In Build |
---|---|---|---|---|---|---|
JDK-2132241 | 5.0u7 | Amit Handa | P2 | Resolved | Fixed | b01 |
Just to make this concrete, here's a small program demonstrating the
problem. Compile and run it, first against 1.4.2, then against
1.5/5.0:
import java.sql.Timestamp;
import java.util.Date;
public class Foo {
public static void main(String[] args) {
Date d = new Date();
Timestamp ts = new Timestamp(d.getTime());
System.out.println(ts.compareTo(d));
}
}
Note that this a *binary compatibility problem*!! The overload
resolution is the same in 1.4.2 and 1.5.0; in either case, it's
compareTo(Date). With a 1.4.2 runtime, it dispatches to the version
defined in java.util.Date, with a 1.5.0 runtime it dispatches to the
version defined in java.sql.Timestamp, which promptly casts its
argument to Timestamp (and blows up). This really feels like a P2 bug
to me.
problem. Compile and run it, first against 1.4.2, then against
1.5/5.0:
import java.sql.Timestamp;
import java.util.Date;
public class Foo {
public static void main(String[] args) {
Date d = new Date();
Timestamp ts = new Timestamp(d.getTime());
System.out.println(ts.compareTo(d));
}
}
Note that this a *binary compatibility problem*!! The overload
resolution is the same in 1.4.2 and 1.5.0; in either case, it's
compareTo(Date). With a 1.4.2 runtime, it dispatches to the version
defined in java.util.Date, with a 1.5.0 runtime it dispatches to the
version defined in java.sql.Timestamp, which promptly casts its
argument to Timestamp (and blows up). This really feels like a P2 bug
to me.
- backported by
-
JDK-2132241 Regression: binary compatibility problem with java.sql.Timestamp.compareTo
-
- Resolved
-
- duplicates
-
JDK-6207898 compareTo in java.util.Date, java.sql.Timestamp don't follow the contract
-
- Closed
-
-
JDK-6304469 REGRESSION: Incompatible to 1.4.xx
-
- Closed
-