Thread-safe java.text.SimpleDateFormat format and parse

[Ben Evans]

Hi Paul,

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
comfort."

Thanks,

Ben

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
> 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.