Thread-safe java.text.SimpleDateFormat format and parse
benjamin.john.evans at gmail.com
Thu Jul 2 10:32:34 UTC 2015
A "small implementation-only change" isn't just about the code.
There's the QA cycles, regression analysis, etc, etc. The cost of a
change isn't just the code, and it also represents the opportunity
cost of *not* making another change.
To do so for a known-broken API (that IMO should be deprecated) is the
equivalent of saying "Lots of people still smoke in bed, despite
everyone knowing how dangerous it is. Let's spend a lot of time &
effort making them a better ashtray so they can do so in more
On Wed, Jul 1, 2015 at 7:33 PM, Paul Draper <paulddraper at gmail.com> wrote:
>> 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