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
Covariant return type refers to return type of an overriding method. It allows to narrow down return type of an overridden method without any need to cast the type or check the return type. Covariant return type works only for non-primitive return types.
How is Covariant return types implemented? Java doesn't allow the return type-based overloading, but JVM always allows return type-based overloading. JVM uses the full signature of a method for lookup/resolution. Full signature means it includes return type in addition to argument types.
A covariant type parameter is marked with the out keyword ( Out keyword in Visual Basic). You can use a covariant type parameter as the return value of a method that belongs to an interface, or as the return type of a delegate.
In Java, arrays are covariant, which has 2 implications. Firstly, an array of type T[] may contain elements of type T and its subtypes. Secondly, an array of type S[] is a subtype of T[] if S is a subtype of T .
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 :(
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With