Question

Previously, when I first design a stock application related software, I decide to use java.util.Date to represent date/time information of a stock.

Later, I realize most of the methods in java.util.Date is deprecated. Hence, very soon, I refactor all my code to make use of java.util.Calendar

However, there is 2 shortcomings I encounter.

1. Construct java.util.Calendar is comparative slower than java.util.Date
2. Within the accessors getCalendar method of Stock class, I need to clone a copy, as Calendar is a mutable class

Here is the current source code for Stock.java

Recently, I discover Joda-Time. I do the following benchmarking, by creating 1,000,000 java.util.Date, java.util.Calendar and org.joda.time.DateTime. I found org.joda.time.DateTime performs better than java.util.Calendar, during instantiation.

Here is the benchmarking result.

This instantiation speed is important, especially many instance of Stocks will be created, to represent a long price history of a stock.

Do you think is it worth to migrate from Java Calendar to Joda Date Time, to gain application speed performance? Is there any trap I need to pay attention to?

Answer 1

Note that java.util.Date is mutable too – so if it’s a problem now you’re using Calendar, it would have been a problem using Date too. That said, using Joda Time is definitely worth doing just because it’s a much, much better API.

How certain are you that performance is actually an issue in your particular app? You say there will be “many instances” of Stock created… how many? Have you profiled it? I wouldn’t expect it to actually make a significant difference in most situations. It’s not obvious from your benchmarking graph what you’re actually measuring.

Moving to Joda Time is a good idea in general, but I would measure the performance to see how much difference it really makes for you.