Given java.time creates a new object on every plus/minus/with call, when (if ever) is this allocation a real concern, and how would you reason about it?

## The mechanic that raises the question Because `java.time` types are immutable, **every** transformation allocates: `d.plusDays(1)` constructs a new `LocalDate`; a loop adding a day 10,000 times constructs ~10,000 objects. A naive reaction is 'isn't that wasteful versus mutating in place?' The principal-level answer is to reason quantitatively rather than reflexively avoid allocation. ## Why it's usually cheap 1. **The objects are tiny.** A `LocalDate` is essentially a few ints (year, month, day). An `Instant` is a long + int. Allocation cost scales with size and these are small. 2. **Generational GC favors short-lived garbage.** The JVM's young generation (eden) uses bump-pointer allocation (incrementing a pointer) and a copying collector that only walks *live* objects. Objects that die young — exactly these throwaway intermediates — are reclaimed almost for free; dead objects are never even visited. So 'lots of short-lived small objects' is the GC's best case, not its worst. 3. **Escape analysis / scalar replacement.** The JIT (C2/Graal) can prove that an intermediate never escapes a method and replace the object with its scalar fields on the stack or in registers, sometimes eliminating the allocation entirely. 4. **No locking, no copying elsewhere.** Immutability removes defensive copies and synchronization you'd otherwise pay for, often a net win. ## When it can actually matter - **Very hot, high-frequency arithmetic**: e.g. a market-data or simulation loop doing millions of date/time computations per second, where allocation rate drives GC frequency and pause time. - **Allocation in the steady-state path** of a latency-sensitive service where even minor GC adds tail latency. - **Object-heavy intermediate types** (e.g. building many `ZonedDateTime`/`DateTimeFormatter`-derived objects) rather than the cheapest primitives. Even then, the discipline is **measure first**: profile allocation (async-profiler, JFR allocation events) and GC logs to confirm `java.time` is the actual hotspot before changing anything. ## How to reduce cost *without* abandoning immutability 1. **Work in primitives, convert once.** Do arithmetic on `long` epoch values (epoch-day, epoch-milli/nano) inside the loop and build a single `java.time` object at the boundary. `LocalDate.toEpochDay()`/`ofEpochDay(long)` and `Instant.toEpochMilli()`/`ofEpochMilli` are designed for this. 2. **Hoist invariants.** Precompute a `Duration`/`Period`/formatter once outside the loop and reuse the immutable instance (sharing is safe). 3. **Avoid redundant conversions.** Don't repeatedly convert between `Instant`, `ZonedDateTime`, and `LocalDateTime`; pick one representation for the hot path. 4. **Batch.** Compute a range with arithmetic (`LongStream` over epoch days) and materialize objects lazily/only when needed. Note what you do **not** do: you never make the types mutable or share a 'reset and reuse' buffer — that would forfeit thread-safety and the discarded-result clarity for a usually-illusory gain. ## The structural-sharing nuance Unlike persistent collections (which share structure between versions), `java.time` values do **not** structurally share — each is an independent small struct. That is fine precisely because they are tiny; structural sharing is a technique for large structures (trees, lists) where copying is expensive, which doesn't apply to a 3-int date. ## The decision framework (what 'principal' looks like here) - Default: immutable, fluent, clear code. - Trigger to optimize: a *measured* allocation/GC hotspot, not a hunch. - Lever: fewer conversions / primitive epoch math / hoisting — never mutability. - Re-measure to confirm the change actually helped and didn't regress correctness (DST, clamping, leap handling).