Alternatives to FastDateFormat for efficient date parsing?

Well aware of performance and thread issues with SimpleDateFormat, I decided to go with FastDateFormat, until I realized that FastDateFormat is for formatting only, no parsing!

Is there an alternative to开发者_JAVA百科 FastDateFormat, that is ready to use out of the box and much faster than SimpleDateFormat?

I believe FastDateFormat is one of the faster ones, so anything that is about as fast would do.

Just curious , any idea why FastDateFormat does not support parsing? Doesn't it seriously limit its use?

Note that since commons-lang 3.2, FastDateFormat supports parsing as well as printing.

See: http://commons.apache.org/proper/commons-lang/apidocs/org/apache/commons/lang3/time/FastDateFormat.html

At a best guess, it's to keep FastDateFormat... well... fast, by limiting it to display only.

Apache Commons DateUtils has a parseDate function, but that uses SimpleDateFormat internally.

An alternative is to use the JodaTime library. It's a complete replacement for dealing with DateFormat, Date, and Calendar objects.

JodaTime has a DateTimeFormatter that can be used to create DateTime objects (JodaTime's equivalent of Java's Date objects) from strings.

An example of how to use it is like this:

String strInputDateTime = "2010-12-27"; // An example, this would really come from outside
DateTimeFormatter fmt = DateTimeFormat.forPattern("yyyy-MM-dd");
DateTime dt = fmt.parseDateTime(strInputDateTime);

I don't know if this is really any faster than SimpleDateFormat, though.

Found something interesting here of this case in Android: http://andmob.wikidot.com/faq-simpletimeformat

SimpleDateFormat, the first time you try parsing (or, presumably, formatting) a date, will load in all the timezone data for your locale. This will take 2-3 seconds. It is hoped that this will be fixed in some future edition of Android.

In the interim, consider using AsyncTask to "warm up" SimpleDateFormat in your process before you need it. Just parse some date in the AsyncTask doInBackground() to get it to load the timezones sometime when it will not impact the user so much. Once initialized in your process, SimpleDateFormat will run quickly until your process is terminated.

As of Java 8, one can use DateTimeFormatter along with the the Java 8 Time API to both parse and format dates. From the documentation:

This class is immutable and thread-safe.

It's recommended to use this class if possible for new work going forward instead of using SimpleDateFormat.

The 'problem' with SimpleDateFormat is not performance, its thread safety.

If you have thousands of threads and synchronizing is not an issue use synchronized (you can also pool the instances to alleviate this a little)

If you have a reasonable amount of threads the recommended way is to have a separate instance for each SimpleDateFormat.

UPDATE

As of Java 8, just use DateTimeFormatter. It is immutable, thread safe, faster, and more flexible. (It also offers nice features like default patterns for ISO-8601 date/time strings.)

Do you really need to parse dates that quickly? Have you tested SimpleDateFormat and found it too slow for your needs?

Note, there are a variety of ways to cache slow-to-construct, non-thread-safe class instances (e.g. ThreadLocal, pools).