Why are java.time types safe to share across threads and cache as constants, unlike java.util.Date and SimpleDateFormat?

## The core property All `java.time` value types — `LocalDate`, `LocalTime`, `LocalDateTime`, `Instant`, `ZonedDateTime`, `OffsetDateTime`, `Duration`, `Period`, plus the formatter `DateTimeFormatter` — are **immutable** and declared **final**. Immutable means their fields are set once at construction and never change; final (class) means no subclass can add mutable state. There are no setters. This is a deliberate JSR-310 design goal. ## Why immutability gives thread safety for free A data race happens when two threads access shared mutable state and at least one writes, without coordination. If the state can **never be written after construction**, there is simply no write to race with. Provided the object is **safely published** (its reference made visible to other threads correctly — e.g. via a `final` field, a `static` field, a `volatile`, or a concurrent collection), every thread sees the fully-constructed, unchanging value. `java.time` types satisfy this because their internal fields are `final`, which the Java Memory Model guarantees are visible after construction. The result: **no locks, no synchronization, no defensive copies** needed to share them. ```java // Perfectly safe shared constant public static final LocalDate PROJECT_EPOCH = LocalDate.of(2020, 1, 1); // Perfectly safe shared formatter private static final DateTimeFormatter ISO = DateTimeFormatter.ISO_LOCAL_DATE; ``` ## The legacy contrast - **`java.util.Date` is mutable**: `setTime(long)` changes the instant in place. If you hand the same `Date` to two parts of a system, one can change it under the other. People worked around this with defensive copies; `java.time` removes the need entirely. - **`SimpleDateFormat` is mutable AND not thread-safe**: it stores intermediate parsing/formatting state (a `Calendar`, internal buffers) in fields during a `format`/`parse` call. Sharing one instance across threads causes interleaved calls to clobber that state — symptoms include wrong dates, `NumberFormatException`, `ArrayIndexOutOfBoundsException`, or values from another thread's request. This is a classic production bug. - **`Calendar` is also mutable** (`add`, `set` mutate in place), the very behavior that trains people to expect mutation and then trip over `java.time`'s discarded-result rule. ## The modern formatter `DateTimeFormatter` was redesigned to be **immutable and thread-safe**. You build it once (it is itself produced fluently/immutably via `withLocale`, `withZone`, etc., each returning a new formatter) and then share that single instance across all threads. So the correct pattern flips: with `SimpleDateFormat` you needed a `ThreadLocal<SimpleDateFormat>` (or a new instance per call); with `DateTimeFormatter` you want **one shared static instance**. ## Practical guidance 1. Store `java.time` values and `DateTimeFormatter`s as `static final` constants or shared fields without fear. 2. Pass them between threads/queues/futures with no copying. 3. Never share a `SimpleDateFormat`; if you must keep legacy code, wrap it in a `ThreadLocal` or, preferably, migrate to `DateTimeFormatter`. 4. Immutability is also why these types make good Map keys and equals/hashCode are stable — the hash can't change after insertion. ## The subtle caveat Immutability guarantees no *internal* mutation, but a **reference variable** can still be reassigned. `private LocalDate cursor` can be pointed at a new value by another thread; if many threads reassign a shared non-final field you still need normal publication (`volatile`/locking) for *that field*. The value itself is always safe; the variable holding it follows ordinary reference-visibility rules.