Reuse Calendar instance during parsing by StdDateFormat

[brenuart]

Addresses issue #1754

I reused the same strategy as for formatting.
A few comments tho:

• TimeZone is reset on the calendar when used if the requested TZ does not match the one set on the reusable calendar.
• Leniency is reset on the calendar as well every time the method _getCalendar is called. I did not add it as a method parameter as leniency is not contextual but set on the StdDateFormat itself.
• As for the Locale we don't care as neither the parse or format method rely on it.

Should be ok I guess...

[Raniz85]

Doesn't this mean that multi-threaded deserialisation runs the risk of concurrently modifying the same calendar instance?

I think it would be a good solution to either use a resource pool or a ThreadLocal to ensure the thread has exclusive access to the Calendar instance.

[brenuart]

Doesn't this mean that multi-threaded deserialisation runs the risk of concurrently modifying the same calendar instance?
The same question is valid for formatting too...
The former StdDateFormat applied the same pattern to create contextual instances of SimpleDateFormat (and its underlying Calendar). Everything was apparently construct with that clone() pattern in mind. How different is it here?

[Raniz85]

You're probably correct

[cowtowncoder]

As per my notes on #1754, I think Calendar instance is actually cloned once per readValue() call and that reuse should be safe.

[cowtowncoder]

.... but I still need to think of if and how to test possibility of concurrency issues. There is RaceCondition738Test which probably could serve as basis...