Proof that old Date Java API is not thread safe

Question

I've been looking for code that demonstrates the kind of stuff that could happen when you use the legacy Date or Calendar classes in a multi-threaded environment, but I can't seem to find any good examples, found a couple with the DateFormatter but nothing only with either of the mentioned two classes anywhere, it is always mentioned they're not thread safe but no code examples!

Would anyone be kind enough to provide a example? Perhaps comparing to the new Java 8 Date classes that are thread safe.

Always assume a class is *not* thread-safe unless the author declares otherwise in the JavaDoc. — Basil Bourque, Aug 18 '18 at 19:13
This answer have the example you are looking for : https://stackoverflow.com/a/4021932/1401019 — Sundararaj Govindasamy, Jun 25 '19 at 18:29

xyz · Answer 1 · 2018-08-06T08:16:45.193

3

First of all java Date is mutable and hold state -> there is a chance Date to be not a threadsafe.

Since java Date contains state ( transient long fastTime) and getter and setter for this field there is a chance Date to be not thread safe.

But when setting and getting a long value is not an atomic operation? If you are running the code in 32bit operation system setting long to a primitive field is not atomic operation, because long and double values were treated as two 32-bit values and that is the reason.

edited Aug 06 '18 at 08:16

answered Aug 06 '18 at 06:25

xyz

812
9
18

2

Although `Date` seemed to be not thread-safe, your rationale does not make sense. Being mutable, stateful and having setter does not necessary mean a class is not thread-safe. – Adrian Shum Aug 06 '18 at 06:53

Proof that old Date Java API is not thread safe

1 Answers1