• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Why do Calendar.after(...) and before(...) take an Object?

 
Jesper de Jong
Java Cowboy
Saloon Keeper
Posts: 15216
36
Android IntelliJ IDE Java Scala Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Class java.util.Calendar has two methods that you can use to see if a calendar is currently set to a date and time after or before that of another Calendar:

public boolean after(Object when)
public boolean before(Object when)

For some strange reason, these methods take an Object as a parameter. According to the Javadoc, that object must be a Calendar. So why is the parameter type Object instead of Calendar?

Is this just a major crazy design bug in the API or is there a reason for this?
 
Paul Sturrock
Bartender
Posts: 10336
Eclipse IDE Hibernate Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
John Kelty
Ranch Hand
Posts: 33
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
Chris Rudd
Greenhorn
Posts: 6
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I would tend to agree with John here - especially since the methods were previously abstract.
 
Jesper de Jong
Java Cowboy
Saloon Keeper
Posts: 15216
36
Android IntelliJ IDE Java Scala Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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:

Ugly!! Bad!!
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic