File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
The moose likes Performance and the fly likes performance problems in calendar classes in jdk 1.5.0    Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » Performance
Bookmark "performance problems in calendar classes in jdk 1.5.0    " Watch "performance problems in calendar classes in jdk 1.5.0    " New topic

performance problems in calendar classes in jdk 1.5.0

ted chang

Joined: Nov 29, 2006
Posts: 1

since upgrading from jdk 1.4.2 to jdk 1.5.0, we are seeing major performance issues in the Calendar class. specifically the before(..), after(...) and equals (...) methods are taking approximately 10 times longer to execute.

i've searched the web and the only other mention of this problem i've found is this link:

has anyone else experienced this problem? is this expected?


Jim Yingst

Joined: Jan 30, 2000
Posts: 18671
I'm guessing this is because of this new method in java.util.Calendar (as of JDK 5):

Specifically, the clone() method looks like a tedious waste of time in most cases. So why do they do it? It's probably in response to the following bugs:


My recommendation would be: don't try to compare Calendars directly. Instead, use either getTime() or getTimeInMillis() to convert the Calendar to a nice simple Date or long. The basic problem is that Calendar & GregorianCalendar are hideously overcomplex beasts which try to do too many things, and most of them poorly. Try to use them only for the operations that need a Calendar (e.g. things that depend on knowing how many days are in a month, and which years are leap years). But use Date or a long to represent actual dates and times. Or, look into Joda-time or TimeAndMoney to make your life simpler.
[ November 30, 2006: Message edited by: Jim Yingst ]

"I'm not back." - Bill Harding, Twister
I agree. Here's the link:
subject: performance problems in calendar classes in jdk 1.5.0
It's not a secret anymore!