Bug ID: JDK-4631234 java.sql.Timestamp.compareTo no longer accepts java.util.Dates in 1.4

Versions (Unresolved/Resolved/Fixed)

The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.

Other
1.4.1 betaFixed

A small change that has been made to java.sql.Timestamp to add a local compareTo() that just calls its superclass (java.util.Date), rather than not declaring it at all and letting the superclass do the job implicitly.  This has apparently been done to fix BugID 4227983 but has the side-effect of stopping them implicitly comparing a Date to a Timestamp, and doing so at Runtime, not at compile time =O(

The text for Date.compareTo(Object) in the javadocs from 1.3.1 onwards state:
     
     "Compares this Date to another Object. If the Object is a Date, this
     function behaves like compareTo(Date). Otherwise, it throws a
     ClassCastException (as Dates are comparable only to other Dates)."
     
The same text for Timestamp says:
     
     "Compares this Timestamp to another Object. If the Object is a Date,
     this function behaves like compareTo(Timestamp). Otherwise, it
     throws a ClassCastException (as Timestamps are comparable only to
     other Timestamps)."
   
It seems quite clear to me that this is a typo, and that first "Date"
should also have been search&replaced to Timestamp.  This is
what led the customer to believe that they were doing an OK thing in
their code in 1.3.x, and it did indeed work back then =O{

Whether the javadocs are correct or not, though, the functionality provided by this addition is definately not - see the Comments section.

CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: hopper-beta FIXED IN: hopper-beta INTEGRATED IN: hopper-beta
14-06-2004
WORK AROUND Explicitly cast the method object to Date: Timestamp t = new Timestamp(7000000); java.util.Date d = new java.util.Date(); int val = ((Date)t).compareTo(d); This basically throws away the nanoseconds explicitly before the call is made, rather than implicitly afterwards.
11-06-2004
PUBLIC COMMENTS Confusion over whether you can compare java.sql.Timestamps to java.util.Dates or not. Comments were changed to indicate that the argument to compareTo(Object o) must be a Timestamp object, meaning that a Timestamp object may be compared only to other Timestamp objects and cannot be compared to Date objects.
10-06-2004
EVALUATION The documentation needs to be modified according to what is described. I.E., the compareTo(Object) method description should say: 'Compares this Timestampe to another Object. If the Object is a Timestamp, this function behavoes like compareTo(Timestampe). Otherwise it throws a a ClassCastExxception (as Timestampes are comparable only to other Timestamps)' Additionally, the compareTo(object) method is implemented in a way to ensure that Timestamps are only compared with Timestamps and to enforce this usage. ###@###.### 2002-02-13
13-02-2002