Thread-safe java.text.SimpleDateFormat format and parse

Paul Draper paulddraper at
Wed Jul 1 18:33:08 UTC 2015

> The suggested approaches would have a negative performance
impact on code which have addressed the thread-safety issues
(by synchronizing, using ThreadLocal instances or similar)

The best approach is to copy a Calendar instance for each call to format()
/ parse().
As I said before, the resulting difference in performance is has been
immeasurable (again, probably because these methods perform many
allocations already).

> It could be for example a new DateFormat subclass that delegates most of
its work to java.time.

I like it, but that may not be possible. For example, I don't know how to
duplicate getCalendar/setCalendar.

> I think we should go a step further and deprecate SimpleDateFormat and
it will save time for everyone

> Given the other problems with the legacy date and time classes, why
spend engineering time tidying this up?

I am not a fan of competing implementations for the same task.
But that said, *lots* of code still uses Date, SimpleDataFormat, etc. For
And Martin has a good point about the Format subclass. I doubt that
deprecating these can happen soon.


I am proposing a small implementation-only change for JDK9 and possibly
earlier(!) that will improve a *very* large amount of existing code.

Larger, sweeping API changes for newer code are very great, but they target
something different, and aren't necessarily "in competition" with this.

More information about the jdk9-dev mailing list