Thread-safe java.text.SimpleDateFormat format and parse

[Paul Draper]

> 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
java.util.Date,
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
example,
https://github.com/search?l=Java&q=simpledateformat+language%3AJava&ref=advsearch&type=Code&utf8=%E2%9C%93
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.