---

Junior Level

The classes LocalDate, LocalTime, LocalDateTime (Java 8+) cannot be modified after creation. Instead of mutating, they return new objects.

LocalDate date = LocalDate.of(2024, 1, 1);
date.plusDays(1);         // date is unchanged!
LocalDate next = date.plusDays(1); // new object — needs to be assigned

Why was it designed this way?

1. Thread-safety — can be used in any thread without synchronization
2. Safety — a method cannot accidentally modify your date
3. Convenience — methods can be chained: date.plusMonths(1).withDayOfMonth(10)

The old Date was mutable — and that’s a problem

Date date = new Date();
date.setYear(120); // Dangerous! Modifies the object

// Bug: mutable Date is changed inside the method
void process(Date d) { d.setTime(d.getTime() + 86400000); } // broke the caller's object!
// LocalDate.plusDays() returns a new object — the original is untouched.

---

Middle Level

Fixing java.util.Date problems

java.util.Date was mutable, which led to:

• Reference leaks — passed a date to a method, and it changed it
• Multi-threading problems — external synchronization needed

Advantages of LocalDate

Thread-safety: can be stored in static constants, shared between threads.

Domain Model integrity: if an order has a creation date, it won’t change from an accidental call.

Cacheable: ideal as keys in HashMap.

Fluent API

LocalDate date = LocalDate.now()
    .plusMonths(1)
    .withDayOfMonth(10)
    .minusDays(3);
// Each call returns a NEW object

All java.time classes are immutable

• LocalDate, LocalTime, LocalDateTime
• Instant, Duration, Period
• ZonedDateTime, OffsetDateTime

When LocalDate immutability has a cost

In high-load systems with millions of timestamps per second, each plusXxx() creates a new object — GC pressure.

---

Senior Level

Value-Based Classes

LocalDate and other java.time classes are Value-Based Classes. They:

• Are immutable
• Compare by value (equals), not by reference
• Can be cached and reused by the JVM
• Have no public constructors (factory methods of(), now())

Memory and performance

LocalDate objects are very small (store only int fields: year, month, day). Creating new objects:

• Minimal overhead — 3 int fields + header
• Modern JVMs handle short-lived objects efficiently
• Safety is worth more than negligible memory overhead

Summary for Senior

• Immutability in java.time — a guarantee of safety and predictability
• Fixing fundamental flaws in java.util.Date
• Value-Based Classes — the standard for modern Java
• All methods return new objects — chaining without side effects

---

Interview Cheat Sheet

Must know:

• LocalDate, LocalTime, LocalDateTime — immutable, each method returns a NEW object
• Fixing java.util.Date problems (mutable, reference leaks, multi-threading issues)
• Fluent API: date.plusMonths(1).withDayOfMonth(10) — chaining without side effects
• Thread-safety: can be stored in static constants, shared between threads
• Value-Based Classes: immutable, compare by equals, can be cached by JVM
• All java.time classes are immutable: Instant, Duration, Period, ZonedDateTime

Frequent follow-up questions:

• Why doesn’t LocalDate modify itself? — To avoid side effects and ensure thread-safety
• What are Value-Based Classes? — Immutable classes, compare by equals, can be cached, no public constructors
• Is there a cost to LocalDate immutability? — GC pressure at millions of timestamps/sec — each plusXxx() = new object
• LocalDate vs Date? — Date is mutable and outdated; LocalDate is immutable and safe

Red flags (do NOT say):

• “date.plusDays(1) changes the date” — returns a NEW object, original is unchanged
• “LocalDate needs synchronization” — thread-safe by default
• “java.util.Date is a good choice” — mutable, outdated, use java.time
• “LocalDate has a public constructor” — no, factory methods of(), now()

Related topics:

• [[1. What is an immutable object]]
• [[2. What advantages do immutable objects provide]]
• [[6. Why are immutable objects thread-safe]]
• [[23. How does immutability affect performance]]