Shared mutable price vs shared immutable price
An immutable object can't change after it's constructed: every "change" returns a new object. Immutable objects are simple to reason about, safe to share between threads, and safe as HashMap keys, which is why String, Integer, LocalDate and records are built that way.
Change the code and press Run (Ctrl+Enter). Try to predict the output first, then break it on purpose and read the error. Your edits are saved and match the lesson page.
Practice questions
Write the code in the editor, run it, then open the model answer to compare.
Write an immutable final class Temperature with a double celsius field, a plus(double delta) method returning a new object, and toString(). Show that the original is unchanged after plus.
Write an immutable final class Playlist holding a List<String> songs with a defensive copy in and an unmodifiable list out, plus withSong(String s) that returns a new playlist. Prove the original doesn't change.
Show that String methods return new objects: call concat, replace and trim on " hi " and print the original afterwards between brackets.
Explain it without notes
List the rules for making a class immutable and explain the reason for each.
Why isn't final enough to make an object immutable?
What is the difference between Collections.unmodifiableList(list) and List.copyOf(list)?
Why are immutable objects thread-safe, and what condition must hold for that guarantee?
Expected output
mutable: A=80 B=80
immutable: original=100 discounted=80
String: s=chai t=CHAI