Migrating from Java Calendar to Joda Date Time

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.

Answer 2

Why do you need a Calendar in your Stock class? I think using a Date to represent a point in time is fine. This seems to be what you want, because you want the Calendar object in the a stock to be immutable, which the Date class should be, if you ignore the deprecated methods.

You can use a temporary Calendar when you need to do time operations on a Date outside the Stock class:

Calendar calendar = Calendar.getInstance();
calendar.setTime(stock.getDate());
System.out.println(calendar.getYear());

Like this you can still store a Date in your Stock class, which should have the best performance when only store and retrieve Stock objects from a data storage. If you do several operations at once you can also reuse the same Calendar object.

If you don't like the Calendar interface you could still use Joda Time to do the time operations. You can probably convert dates to and from Joda Time if needed, to do time operations, and still store Date objects in your Stock class.

Answer 3

If java.util.Calendar instances to be replaced with org.joda.time.DateTime are parsed and/or formatted to a particular pattern, e.g.

String format = "YYYY-MM-dd HH:mm:ss";

1. Within method signatures for parameter and return types, as well as variable declarations

and instantiations, repace whole word occurrences of the class names Calendar (with

DateTime) and SimpleDateFormat (with DateTimeFormatter), respectively

2. Replace the formatter instantiation statement, e.g.

   formatter = new SimpleDateFormat(format);
   

   with

   formatter = DateTimeFormat.forPattern(format);
   

3. Replace calls to methods of `SimpleDateFormat', e.g.

   String dateStr = formatter.format(Calendar.getInstance().getTime());
   

   with

   String dateStr = DateTime.now().toString(formatter);
   

   and

   formatter.parse(dateStr);
   

   with

   DateTime.parse(dateStr, formatter);
   

Answer 4

I used Joda in the past, and it is an awesome library.

In terms of performance, you'll have to test it, unfortunately. But refactoring your code seems too much. Personally, I used Date throughout my whole application (including DB store and retrieve), and used Joda only when I needed data manipulation. Joda calculates fields only when needed, so I guess the overhead will be much lower than using Java API classes; furthermore, you won't have object version issues to transfer and handle Date objects in your DB, serialize objects and such. I don't expect Joda to break such compatibility, but it is less likely using Date.

Answer 5

It is always better to move to joda-time in general. But it it is really worth to move to the joda-time for your project is based on your use-cases pertaining to the date usage. Look at slide number 46 in the presentation for performance related numbers for some of the operationslink text