How do covariant parameter types work in java

Question

Given that Date has a method called "after(Date)" and Timestamp has a method the overrides it called "after(Timestamp)", why is the after method in Date called in the following code?

The question as to the unexpected results was asked here .

    java.sql.Timestamp one = new java.sql.Timestamp(1266873627200L);
    java.sql.Timestamp two = new java.sql.Timestamp(1266873627000L);

    java.util.Date oneDate = (java.util.Date) one;
    java.util.Date twoDate = (java.util.Date) two;


    System.out.println("one: " + oneDate.getTime());
    System.out.println("two: " + twoDate.getTime());

    if (oneDate.after(twoDate)) {
        System.out.println(oneDate.getTime() + " after " + twoDate.getTime());
    } else {
        System.out.println(oneDate.getTime() + " not after " + twoDate.getTime());
    }

results

one: 1266873627200
two: 1266873627000
1266873627200 not after 1266873627000

Answer 1

Overloads are considered at compile-time; overrides are considered at execution time.

Timestamp overloads after , it doesn't override an existing method - so your oneDate.after(twoDate) is only considering the methods in java.util.Date ; furthermore even if you use one.after(twoDate) it would still only use after(Date) because the compile-time type of twoDate is Date rather than Timestamp .

If you call one.after(two) then that will use Timestamp.after(Timestamp) .

Date.after(Date) only considers the milliseconds - but Timestamp only passes an integral number of seconds to the constructor of Date , so oneDate and twoDate have an equal millisecond value in Date , even though you passed different values to the constructors.

It's worth noting this bit in the docs for Timestamp though:

Due to the differences between the Timestamp class and the java.util.Date class mentioned above, it is recommended that code not view Timestamp values generically as an instance of java.util.Date. The inheritance relationship between Timestamp and java.util.Date really denotes implementation inheritance, and not type inheritance.

Sounds like a pretty poor use of inheritance to me, to be honest - but then Java's got plenty of those :(