Java and anything to do with dates just seems to be badly done. I can't think of a good reason. But then maybe I'm just bitter after spending an afternoon fixing jdk1.5 introduced ClassCastExceptions in TimeStamp's compareTo method.
I suppose it could be so that developers could write subclasses of Calendar that work with various data types, maybe Date, or maybe some proprietary class, without breaking the Calendar.before(Object when) method signature.
That doesn�t make it right, but that�s my guess as to why they did it that way.
Ok, but it doesn't really make sense, or at least, it's not type safe.
Suppose I'd write my own Calendar class, with an after(...) method that would be able to accept a Calendar as well as a Date. The most straightforward and type safe way would be to simply overload the after(...) method:
If I want to do this with the current Calendar API, I'm forced to write my after(...) method in a non-OO and non-type safe way:
subject: Why do Calendar.after(...) and before(...) take an Object?