Effective Java

Item 1 — Why should you consider static factory methods instead of public constructors?

🔴 Problem Constructors are anonymous — BigInteger(int, int, Random) tells you nothing about what it returns. They must always allocate a new object. They can only return the exact declared type, never a subtype.

🟠 If you ignore this Unreadable APIs with ambiguous parameter order (easy to swap silently). No instance caching possible. Return type is rigid — no interface-based design, no service-provider patterns like JDBC.

🟢 Solution Use a public static method that returns an instance. Stick to naming conventions: of, from, valueOf, getInstance, create, newInstance, getType, newType.

🔵 Why it works 5 advantages over constructors: (1) have meaningful names, (2) can return a cached instance, (3) can return any subtype, (4) return type can vary by input parameters, (5) returned class doesn't need to exist at write time. Trade-offs: classes without public constructors can't be subclassed, and static factories are hard to spot in Javadoc.

☕ Code

java

// BAD
Boolean b = new Boolean(true); // always allocates, no name

// GOOD
Boolean b = Boolean.valueOf(true); // cached, self-documenting

Java 17 (work): ⚠ Apply the book's solution. The language does not solve this for you — you still write static factories by hand. The one thing Java 8 already fixed: interfaces can now have static methods, so you no longer need a companion class like Collections. But the core advice is unchanged.

Java 21 (personal): ⚠ Apply the book's solution. Still not solved by the language. Actually more powerful now — combine static factories with sealed types and the factory decides which permitted subclass to return, keeping the whole hierarchy hidden from callers.

Item 2 - How do you enforce that a class has exactly one instance, and what's the safest approach?

🔴 Problem You need exactly one instance of a class (e.g. a system component, a stateless service). Two naive approaches exist — public final field or static factory — but both break under reflection attacks and require extra boilerplate to survive serialization.

🟠 If you ignore this A privileged client can call your private constructor via AccessibleObject.setAccessible() and create a second instance. Serializing and deserializing creates a brand new instance, silently breaking the singleton guarantee.

🟢 Solution Three approaches — in order of preference:

1. Enum singleton (preferred): public enum Elvis { INSTANCE; }

2. Static factory: public static Elvis getInstance() { return INSTANCE; }

3. Public final field: public static final Elvis INSTANCE = new Elvis();

🔵 Why it works The enum approach is concise, serialization-safe out of the box, and reflection-proof — the JVM guarantees enum instances are unique. The only limitation: your singleton can't extend a superclass other than Enum. In that case, use the static factory approach and add a readResolve() method to survive serialization.

☕ Code

java

// PREFERRED — enum singleton
public enum Elvis {
    INSTANCE;
    public void leaveTheBuilding() { ... }
}

// If you must extend a class — static factory + readResolve
public class Elvis {
    private static final Elvis INSTANCE = new Elvis();
    private Elvis() { }
    public static Elvis getInstance() { return INSTANCE; }

    private Object readResolve() { return INSTANCE; } // survives serialization
}

Java 17 (work): ⚠ Apply the book's solution. No language feature enforces singletons for you. Enum singleton is still the right default. If you need to extend a class, use the static factory + readResolve approach.

Java 21 (personal): ⚠ Apply the book's solution. Unchanged — records are not singletons (they can be instantiated freely). Enum singleton remains the safest approach.

Item 4 — How do you prevent a utility class from being instantiated?

🔴 Problem Utility classes (pure static methods/fields, like Math or Collections) should never be instantiated. But if you define no constructor, the compiler silently generates a public no-arg one — making your class accidentally instantiable.

🟠 If you ignore this Users can write new MathUtils() — meaningless but valid. Making the class abstract doesn't fix it: someone can subclass it and instantiate the subclass. Worse, abstract misleads readers into thinking the class was designed for inheritance.

🟢 Solution Declare a private constructor that throws AssertionError:

java

private UtilityClass() {
    throw new AssertionError(); // never called
}

🔵 Why it works No explicit constructor → compiler generates one. Private constructor → no outside instantiation. AssertionError → even accidental internal calls fail loudly. Bonus side-effect: also prevents subclassing, since every subclass constructor must invoke a superclass constructor, and this one is inaccessible.

☕ Code

java

public class MathUtils {
    // Private constructor — this class is not meant to be instantiated
    private MathUtils() {
        throw new AssertionError();
    }

    public static int square(int x) { return x * x; }
}

Java 17 (work): ⚠ Apply the book's solution. Since Java 8 you can put static methods directly on interfaces, so you may need utility classes less often. But when you do have one, the private constructor is still the only correct way to block instantiation.

Java 21 (personal): ⚠ Apply the book's solution. No change. If your utility class only groups static helpers, also ask yourself if a sealed interface with no implementations would express intent better — but the private constructor idiom is still correct for traditional utility classes.

Item 5 — Why shouldn't a class hardwire its own dependencies, and what should you do instead?

🔴 Problem Classes that create or hardwire their own dependencies (as a static utility or singleton) assume there is only one valid version of that resource. A SpellChecker that hardwires its Dictionary can never be used with another language's dictionary, a test dictionary, or a special-purpose vocabulary.

🟠 If you ignore this The class becomes inflexible — you can't swap the resource without changing the class itself. It becomes untestable — you can't inject a mock. Making the field non-final and adding a setter "fixes" this but introduces a mutable, thread-unsafe mess.

🟢 Solution Pass the resource into the constructor at creation time — this is dependency injection. For more flexibility, pass a factory (Supplier<T>) instead of a concrete instance, so the caller controls how instances are created.

🔵 Why it works The class stays immutable and thread-safe. Any number of resources or dependency graphs are supported. The same pattern works with constructors, static factories, and builders. For large projects with thousands of dependencies, frameworks like Spring, Guice, or Dagger wire everything automatically — and they work perfectly with classes designed for manual DI.

☕ Code

java

// BAD — hardwired, inflexible, untestable
public class SpellChecker {
    private static final Lexicon dictionary = new EnglishLexicon();
    private SpellChecker() {}
    public static boolean isValid(String word) { ... }
}

// GOOD — dependency injected, flexible, testable
public class SpellChecker {
    private final Lexicon dictionary;

    public SpellChecker(Lexicon dictionary) {
        this.dictionary = Objects.requireNonNull(dictionary);
    }
    public boolean isValid(String word) { ... }
}

// BONUS — factory variant for deferred/repeated creation
Mosaic create(Supplier<? extends Tile> tileFactory) { ... }

Java 17 (work): ⚠ Apply the book's solution. Nothing in Java 17 solves this for you. Constructor injection is still the right default. In a Spring or Quarkus project you'll use @Autowired / @Inject, but those only work because the class was designed for DI in the first place — the book's advice is what makes that possible.

Java 21 (personal): ⚠ Apply the book's solution. No change. Records make constructor injection even more natural — a record's canonical constructor is a perfect injection point and immutability is enforced automatically. Still no language-level DI; you still wire it yourself or via a framework.

Item 6 — What are the most common ways Java developers accidentally create unnecessary objects, and how do you avoid them?

🔴 Problem Three common traps cause needless object creation: (1) constructing objects that could be reused (new String("x")), (2) recreating expensive objects on every call (a Pattern compiled inside a loop), and (3) autoboxing primitives into wrapper types without realising it (Long sum = 0L in a loop).

🟠 If you ignore this String literals in loops create millions of pointless instances. Calling String.matches() repeatedly recompiles the regex into a Pattern each time — 6x slower than caching it. A single Long instead of long in a summation loop silently allocates ~2 billion Long objects, turning a 0.6s operation into 6.3s.

🟢 Solution

• Use string literals, not new String("...").

• Prefer static factory methods over constructors on immutable classes (Boolean.valueOf() never allocates).

• Cache expensive objects as static final fields (compile Pattern once at class load).

• Always use primitives (long, int) over boxed types (Long, Integer) in local variables and loops.

🔵 Why it works Immutable objects are always safe to reuse. Caching at class initialization is free if the method is called at all, and simpler than lazy initialization. The JVM interns string literals automatically. Note the counterpoint: this is not a reason to build your own object pool — the GC handles lightweight objects better than any manual pool. And never sacrifice defensive copying (Item 50) for the sake of reuse.

☕ Code

java

// BAD — new String() is always wasteful
String s = new String("bikini");

// GOOD — reuses the interned literal
String s = "bikini";

// BAD — recompiles the regex on every call
static boolean isRomanNumeral(String s) {
    return s.matches("^(?=.)M*(C[MD]|D?C{0,3})...$");
}

// GOOD — compile once, cache forever
private static final Pattern ROMAN =
    Pattern.compile("^(?=.)M*(C[MD]|D?C{0,3})...$");

static boolean isRomanNumeral(String s) {
    return ROMAN.matcher(s).matches(); // 6.5x faster
}

// BAD — Long instead of long = ~2 billion autoboxed objects
Long sum = 0L;
for (long i = 0; i <= Integer.MAX_VALUE; i++) sum += i;

// GOOD
long sum = 0L;
for (long i = 0; i <= Integer.MAX_VALUE; i++) sum += i;

Java 17 (work): ⚠ Apply the book's solution. Nothing in Java 17 fixes autoboxing or Pattern recompilation for you. The traps are identical. If anything, streams make autoboxing bugs easier to hide — always prefer LongStream, IntStream over Stream<Long> for numeric work.

Java 21 (personal): ⚠ Apply the book's solution. Same traps exist. Value types (Project Valhalla) aim to eliminate the cost of boxing entirely, but that is not in Java 21. Virtual threads (Java 21) don't change object allocation costs. Stay disciplined with primitives and cached statics.

Item 7 - How do you prevent memory leaks in a garbage-collected language like Java?

🔴 Problem Obsolete object references — references that will never again be dereferenced but are still held by a live object. This prevents the garbage collector from reclaiming the memory, leading to "memory leaks" (more accurately called "unintentional object retentions").

🟠 If you ignore this Disk paging or OutOfMemoryError failures can occur. Even if the leak is small, it can cause performance degradation by increasing garbage collection frequency and duration.

🟢 Solution Null out references as soon as they become obsolete. This is especially important for classes that manage their own memory, such as a custom Stack or Cache. Additionally, use WeakHashMap for caches where the entry should be removed when its key is no longer referenced externally.

🔵 Why it works Nulling references makes it clear to the JVM that the object is no longer needed. It also provides a fail-fast benefit: if the program mistakenly attempts to use a nulled reference, it will throw a NullPointerException immediately rather than silently doing the wrong thing.

☕ Code

Java

// BAD: Obsolete references stay in the elements array
public Object pop() {
    if (size == 0) throw new EmptyStackException();
    return elements[--size]; 
}

// GOOD: Manual nulling for memory-managed classes
public Object pop() {
    if (size == 0) throw new EmptyStackException();
    Object result = elements[--size];
    elements[size] = null; // Eliminate obsolete reference
    return result;
}

Java 17 (work): ⚠ Apply the book's solution The JVM still cannot know when an element in a private array is "logically" dead. You must still manually null out references in classes that manage their own memory.

Java 21 (personal): ⚠ Apply the book's solution While modern GCs like ZGC are more efficient, they still cannot reclaim objects that are reachable through live references. The core advice for memory-managed containers remains essential.

Item 8 - Why should you avoid using finalizers and cleaners for general resource management?

🔴 Problem Finalizers (finalize()) and cleaners are unpredictable, often dangerous, and generally unnecessary. There is no guarantee they will be executed promptly, or even at all.

🟠 If you ignore this Resources like file handles or sockets may stay open indefinitely, leading to system failure because the system cannot open new files. Finalizers can also swallow exceptions and create severe security vulnerabilities (Finalizer Attacks).

🟢 Solution Have your class implement AutoCloseable and require clients to call close(), typically using a try-with-resources block. Use cleaners only as a "safety net" for resources or for cleaning up non-Java (native) peers.

🔵 Why it works

AutoCloseable coupled with try-with-resources ensures timely and predictable resource release regardless of whether the block completes normally or abruptly. Cleaners are slightly safer than finalizers because they don't allow access to the instance being destroyed, but they still suffer from GC-dependency.

☕ Code

Java

// BAD: Depending on finalization (unpredictable)
public class Resource {
    @Override protected void finalize() {
        // Close file handles here - DON'T DO THIS
    }
}

// GOOD: Using AutoCloseable
public class Resource implements AutoCloseable {
    @Override
    public void close() {
        // Predictable cleanup
    }
}

// Usage
try (Resource r = new Resource()) {
    // Work with resource
} // close() is called automatically here

Java 17 (work): ✅ Already solved by the language The finalize() method was deprecated in Java 9. In Java 17, it is deprecated for removal. You should treat its use as a bug and strictly use AutoCloseable or java.lang.ref.Cleaner.

Java 21 (personal): ✅ Already solved by the language

Java 21 continues the push to remove finalizers. For modern concurrency (Virtual Threads), blocking in a finalizer would be particularly detrimental; try-with-resources remains the standard for safe resource management.

Item 9 - Item 9: Prefer try-with-resources to try-finally.

🔴 Problem When using resources that must be closed (like InputStream or java.sql.Connection), the traditional try-finally block is verbose and error-prone. If exceptions occur in both the try block and the finally block, the second exception suppresses the first, making debugging nearly impossible as the root cause is lost.

🟠 If you ignore this You risk resource leaks if the finally block isn't written perfectly. More critically, you may face "missing" exceptions where the stack trace only shows the error from the close() call, hiding the actual logic error that caused the crash.

🟢 Solution Use the try-with-resources statement. To be used, a resource must implement the AutoCloseable interface. This structure handles multiple resources cleanly and ensures all are closed, even if exceptions are thrown.

🔵 Why it works It provides better readability and automatically handles suppressed exceptions. The JVM captures the subsequent exceptions but keeps the first one as the primary, attaching others to it via the addSuppressed method so they still appear in the stack trace.

☕ Code

Java

// BAD: try-finally (Nested/Messy)
InputStream in = new FileInputStream(src);
try {
    OutputStream out = new FileOutputStream(dst);
    try {
        // work
    } finally {
        out.close(); // If this fails, it might mask errors above
    }
} finally {
    in.close();
}

// GOOD: try-with-resources (Clean)
try (InputStream in = new FileInputStream(src);
     OutputStream out = new FileOutputStream(dst)) {
    // work
} catch (IOException e) {
    // Handle errors; resources are already closed here
}

Java 17 (work): ✅ Already solved by the language Try-with-resources was introduced in Java 7 and refined in Java 9 to allow effectively final variables to be used in the resource specification. In Java 17, there is no reason to ever use try-finally for resource closing.

Java 21 (personal): ✅ Already solved by the language Standard practice remains unchanged. It is the mandatory way to handle resources, especially with newer features like StructuredTaskScope which also often follow an auto-closing pattern.

Item 10: Obey the general contract when overriding equals.

🔴 Problem Overriding equals seems simple but is full of traps. The Object contract requires it to be Reflexive, Symmetric, Transitive, Consistent, and Non-null. Violating these properties breaks fundamental collection classes like HashMap and HashSet.

🟠 If you ignore this Objects that are logically "equal" will behave unpredictably in collections. You might add an object to a Set and then be unable to find it, or a List.contains(x) check might return false even when a matching object is present.

🟢 Solution Use this recipe: 1) Use == for identity check; 2) Use instanceof to check type; 3) Cast to correct type; 4) Check "significant" fields (use == for primitives, Objects.equals for objects, and Float.compare / Double.compare for floats/doubles).

🔵 Why it works By following the rigid contract, you ensure your class plays nicely with all other Java libraries. It prevents subtle bugs related to inheritance (like the "Point vs ColorPoint" symmetry problem) by ensuring that equality is only established between compatible types.

☕ Code

Java

// BAD: Manual implementation prone to nulls or type errors
public boolean equals(Object o) {
    MyClass other = (MyClass) o; // ClassCastException risk!
    return this.id == other.id;  // NullPointer risk if o is null!
}

// GOOD: Following the contract
@Override public boolean equals(Object o) {
    if (o == this) return true;
    if (!(o instanceof MyClass)) return false;
    MyClass m = (MyClass) o;
    return m.id == id && Objects.equals(m.name, name);
}

Java 17 (work): ✅ Already solved by the language Use Java Records. Introduced as a standard feature in Java 16, records automatically generate a perfect equals (and hashCode/toString) implementation based on the state components, following Bloch's advice perfectly without boilerplate.

Java 21 (personal): ✅ Already solved by the language Same as Java 17—Records are the preferred way to create data-carrier classes. If you must use a standard class, use an IDE or a library like Lombok to generate the code to ensure you don't miss a field or break the contract.

Item 12 - Always override toString.

🔴 Problem The default implementation in Object is uninformative: it consists of the class name followed by an "@" sign and the unsigned hexadecimal representation of the hash code (e.g., PhoneNumber@163b91).

🟠 If you ignore this Debugging becomes significantly harder. Log messages, stack traces, and debugger inspections will show cryptic IDs instead of the actual state of the object, forcing you to manually inspect fields to understand the program's state.

🟢 Solution

• Return all of the interesting information contained in the object.

  
  

• Clearly document whether or not you are specifying the format of the return value.

• Provide programmatic access (getters) to all information contained in the string so users don't have to parse the string to get data.

🔵 Why it works A good toString makes your class much more pleasant to use and makes systems using the class easier to debug. If you specify the format (like for a Date or BigInteger), it can be used as a standard data representation; if you don't specify it, you retain the flexibility to improve it in the future.

☕ Code

Java

// BAD: Default toString
// Prints: User@7a353d95

// GOOD: Descriptive toString
@Override public String toString() {
    return String.format("User(id=%d, name=%s, role=%s)", id, name, role);
}
// Prints: User(id=42, name=jbloch, role=ADMIN)

Java 17 (work): ✅ Already solved by the language Records automatically provide a string representation that lists all the record's components and their values (e.g., PhoneNumber[areaCode=707, prefix=867, lineNum=5309]).

Java 21 (personal): ✅ Already solved by the language While Records solve this for data classes, Java 21's String Templates (preview feature in 21) make writing manual toString methods significantly cleaner and less error-prone if you aren't using a record.

Item 13 - Override clone judiciously.

🔴 Problem The Cloneable interface is widely considered a broken design. It doesn't contain any methods; instead, it determines the behavior of Object’s protected clone method. If a class implements Cloneable, Object.clone returns a field-by-field copy of the object; otherwise, it throws CloneNotSupportedException. This "mixin" style of interface is highly unconventional and dangerous.

🟠 If you ignore this You risk creating "shallow copies" where the clone and the original share internal state (like arrays or mutable objects). If a user modifies the clone's internal state, the original is silently corrupted. Furthermore, the clone method functions as a "hidden constructor," bypassing normal object creation rules and potentially breaking class invariants.

🟢 Solution

• Avoid clone entirely for most classes.

• Use a copy constructor (e.g., public Yum(Yum yum)) or a copy factory (e.g., public static Yum copyOf(Yum yum)).

  
  

• These alternatives are safer, don't throw checked exceptions, don't require casts, and can take an interface as an argument (e.g., new ArrayList<>(collection)).

  
  

🔵 Why it works Copy constructors and factories are not bound by the rigid, buggy contract of clone. They rely on normal constructor mechanisms, handle final fields correctly, and allow for "conversion constructors" where you can copy a HashSet into a TreeSet seamlessly.

☕ Code

Java

// BAD: Using clone (fragile, requires cast and exception handling)
@Override public MyClass clone() {
    try {
        return (MyClass) super.clone();
    } catch (CloneNotSupportedException e) {
        throw new AssertionError(); // Can't happen
    }
}

// GOOD: Copy Constructor (safe, simple, flexible)
public MyClass(MyClass other) {
    this.field1 = other.field1;
    this.field2 = other.field2.clone(); // If field2 is a primitive array
}

Java 17 (work): ⚠ Apply the book's solution

The clone method remains a legacy pitfall in Java 17. Use copy constructors or factories. For simple data holders, consider Records, though they don't have a built-in "copy" syntax; you still manually call the constructor with the old object's fields.

Java 21 (personal): ⚠ Apply the book's solution

Java 21 doesn't change the status of clone. However, Records combined with potential future "withers" (derived from JEP 468) are the modern direction for state copying, reinforcing the move away from Cloneable.

Item 14 - Consider implementing Comparable.

🔴 Problem When a class has a natural ordering (like dates, names, or numerical values), failing to implement Comparable prevents it from working with a vast array of generic algorithms and collections that rely on comparison.

🟠 If you ignore this Your class cannot be sorted automatically using Arrays.sort() or Collections.sort(). It will also fail to work correctly as a key in a TreeMap or as an element in a TreeSet, which require objects to have a defined order to maintain their internal structure.

🟢 Solution

• Implement the compareTo method.

• 
  

  Do not use < or > operators for primitive types (except float/double); use the static compare methods in boxed classes like Integer.compare or Long.compare.

  
  

• For complex classes, use the Comparator construction methods introduced in Java 8 for a clean, fluent implementation.

  
  

🔵 Why it works Implementing Comparable allows your class to interoperate with all of Java's sorting and searching infrastructure. Using Comparator builders reduces boilerplate and the risk of integer overflow errors (a common bug in manual compareTo math like x - y).

☕ Code

Java

// BAD: Manual subtraction (Risk of integer overflow!)
public int compareTo(PhoneNumber pn) {
    return this.areaCode - pn.areaCode; 
}

// GOOD: Using static compare or Comparator builders
private static final Comparator<PhoneNumber> COMPARATOR =
    comparingInt((PhoneNumber pn) -> pn.areaCode)
        .thenComparingInt(pn -> pn.prefix)
        .thenComparingInt(pn -> pn.lineNum);

public int compareTo(PhoneNumber pn) {
    return COMPARATOR.compare(this, pn);
}

Java 17 (work): ⚠ Apply the book's solution

The advice to use static compare methods or Comparator chains is the standard in Java 17. If using Records, you still must manually implement Comparable as it is not auto-generated.

Java 21 (personal): ⚠ Apply the book's solution

Java 21 maintains this pattern. While pattern matching and records make handling complex data easier, the fundamental need for a compareTo method in ordered collections remains unchanged.

Item 15: Minimize the accessibility of classes and members

🔴 Problem: Excessive Accessibility

Components that expose too much of their internal state—whether through public classes, public fields, or overly permissive access modifiers—tightly couple the system. This makes code fragile, difficult to refactor, and impossible to optimize without breaking existing clients.

🟠 If you ignore this

• Maintenance Burden: You become obligated to support internal implementation details forever to maintain backward compatibility.

• Security Vulnerabilities: Exposing mutable objects (like arrays or lists) allows external clients to modify your internal state, potentially leading to security holes or corrupt data.

• Brittle Decompositions: Systems become rigid; changing one class forces changes across the entire codebase because other components depend on implementation details rather than abstract APIs.

🟢 Solution

• The Rule of Thumb: Make each class or member as inaccessible as possible.

• Default to private: Design your public API carefully, then make everything else private. Only loosen access (to package-private or protected) if absolutely necessary.

• Protect Constants: Never expose mutable arrays as public static final fields. Instead, use private arrays with either an unmodifiable list or a method that returns a .clone() of the array.

• Avoid Public Fields: Public classes should not have public instance fields. Use getters and setters (or records) to maintain control over invariants and thread safety.

🔵 Why it works

Information hiding decouples components, enabling parallel development, easier debugging, and effective performance tuning. When implementation details are hidden, you can replace or optimize a component without fear of harming the rest of the system.

☕ Code

Java

// BAD: Security hole! Client can modify array contents.
public static final Thing[] VALUES = { ... };

// GOOD: Private array with an unmodifiable list wrapper
private static final Thing[] PRIVATE_VALUES = { ... };
public static final List<Thing> VALUES = 
    Collections.unmodifiableList(Arrays.asList(PRIVATE_VALUES));

// ALTERNATIVE GOOD: Private array with a clone accessor
private static final Thing[] PRIVATE_VALUES = { ... };
public static final Thing[] values() {
    return PRIVATE_VALUES.clone();
}

Java 17 (work): ⚠ Apply the book's solution

The principle remains foundational. While record types in Java 17 provide a cleaner way to handle immutable data, the access modifiers still dictate whether those records act as internal implementation or exported API.

Java 21 (personal): ⚠ Apply the book's solution

The advice holds firm in modern Java. While Java 9+ modules introduced implicit access levels for packages, they are largely advisory for application code. Relying on strict private/package-private discipline remains your most effective tool for encapsulation.

Item 16: In public classes, use accessor methods, not public fields

🔴 Problem: Degenerate Classes

Public classes that use direct field access (public double x;) instead of encapsulation provide no protection for their internal data. This prevents you from changing the class's internal representation, enforcing invariants, or adding side effects (like logging or validation) when a field is accessed.

🟠 If you ignore this

• API Rigidity: Once you expose a public field, the internal representation becomes part of your API. Changing it later will break every client currently using that class.

• Loss of Invariants: You cannot prevent invalid values (e.g., negative time) from being assigned to public mutable fields.

• Performance Debt: You lose the ability to perform lazy initialization or add caching, potentially leading to long-term performance issues that are impossible to fix without a breaking API change.

🟢 Solution

• For Public Classes: Always use private fields with public accessors (getters) and mutators (setters).

• For Package-Private/Private Nested Classes: You may expose fields directly if it simplifies the code and reduces "visual clutter," as the impact is localized to that package or class.

• Immutable Fields: While exposing public final fields in public classes is "less harmful" than mutable ones (as they can still enforce invariants), it is still considered poor practice because it prevents future flexibility.

🔵 Why it works

Encapsulation creates a "layer of indirection." By using accessors, the internal structure of the data can evolve (e.g., changing from int to long, or switching to calculated values) without impacting the classes that consume your API.

☕ Code

Java

// BAD: Degenerate class (No encapsulation)
public class Point {
    public double x;
    public double y;
}

// GOOD: Encapsulated class
public class Point {
    private double x;
    private double y;

    public Point(double x, double y) {
        this.x = x;
        this.y = y;
    }

    // Accessors allow future changes to internal representation
    public double getX() { return x; }
    public void setX(double x) { this.x = x; }
}

Java 17 (work): ⚠ Apply the book's solution

Use Records for simple data-carrying classes where the internal representation is the API. If you need to enforce invariants, define a compact constructor in the record to validate inputs; otherwise, standard classes with accessors remain the rule for mutable state.

Java 21 (personal): ⚠ Apply the book's solution

Java 21 features like Pattern Matching and Records are excellent for immutable data, but they do not change the underlying rule: never expose mutable fields in a public API. If your class must be mutable, encapsulate it with methods to ensure your object remains in a valid state.

Item 17: Minimize mutability

🔴 Problem: Unnecessary Mutability

Designing classes to be mutable by default—providing setters for every getter—increases state space complexity, makes thread safety difficult, and creates "brittle" objects where invariants can be broken by any component with a reference to the object.

🟠 If you ignore this

• Thread Safety Issues: Mutable objects require complex synchronization to avoid data corruption when accessed concurrently.

• Fragile Invariants: Your class cannot guarantee its own validity over time if clients can modify its state at will.

• Failure Atomicity Loss: If a method fails midway through a series of state changes, the object is left in an inconsistent, "corrupted" state.

🟢 Solution

1. Remove Mutators: Never provide methods that modify the object's state.

2. Finality: Make the class final (or use private constructors with static factories) and ensure all fields are private final.

3. Defensive Copies: Never share references to internal mutable components; perform defensive copies in constructors and accessors.

4. Functional Approach: Instead of modifying state, have methods (e.g., plus, minus) return a new instance representing the result.

5. Effective Finality: If you must have mutable state, keep the state space as small as possible and never allow "reinitialization" methods.

🔵 Why it works

Immutable objects are inherently thread-safe and cannot be corrupted. Because their state is fixed, you never need to synchronize access, copy them defensively, or worry about them changing unexpectedly when used as Map keys or Set elements.

☕ Code

Java

// BAD: Procedural approach (Modifies internal state)
public void add(Complex c) {
    this.re += c.re;
    this.im += c.im;
}

// GOOD: Functional approach (Returns new instance, keeps state fixed)
public Complex plus(Complex c) {
    return new Complex(this.re + c.re, this.im + c.im);
}

Java 17 (work): ⚠ Apply the book's solution

Use record types! Records are immutable by default, provide canonical constructors, and handle equals()/hashCode() automatically. They perfectly align with the goal of minimizing mutability for data-carrying classes.

Java 21 (personal): ⚠ Apply the book's solution

Java 21 continues to emphasize immutability. When you need complex state, combine records with the Functional Approach. If performance becomes a bottleneck with many short-lived objects, follow the book's advice: provide a "mutable companion" (like StringBuilder for String) only after profiling proves it is necessary.

Item 18: Favor composition over inheritance

🔴 Problem: Fragile Inheritance

Implementation inheritance (extending concrete classes) violates encapsulation. It forces the subclass to depend on the internal implementation details of the superclass. If the superclass implementation changes—or if it adds new methods in a future release—the subclass can break silently, leading to bugs that are difficult to diagnose.

🟠 If you ignore this

• Tight Coupling: Your subclass is "glued" to the superclass's internals. You cannot optimize, modify, or debug the superclass without risking the integrity of your subclass.

• Fragility: Adding new methods to a superclass can clash with your subclass's methods, causing compilation errors or unintended overrides.

• Leaky Abstractions: The superclass's API flaws (like Hashtable's non-string keys in Properties) are automatically inherited and propagated into your own API.

🟢 Solution

• Favor Composition: Instead of extending a class, give your class a private field that holds an instance of the class you want to reuse.

• Use Forwarding: Create methods in your new class that simply call the corresponding methods in the contained instance. This is known as forwarding.

• Use Interfaces: If possible, implement an interface (e.g., Set) and use a "Forwarding Class" to handle the boilerplate, allowing you to wrap any implementation of that interface.

• The "Is-A" Test: Only use inheritance if an absolute "is-a" relationship exists. If a Stack is not a Vector, do not extend Vector.

🔵 Why it works

Composition separates your class's API from the implementation of the wrapped component. You control the interactions, meaning you can add instrumentation or security checks without worrying about "self-use" bugs (like the HashSet.addAll double-counting issue) or implementation changes in the superclass.

☕ Code

Java

// BAD: Inheritance (Fragile, double-counts elements)
public class InstrumentedHashSet<E> extends HashSet<E> {
    // Overrides can break if superclass implementation changes
}

// GOOD: Composition and Forwarding (Robust, works with any Set)
public class InstrumentedSet<E> implements Set<E> {
    private final Set<E> s; // Composition
    public InstrumentedSet(Set<E> s) { this.s = s; }

    // Forwarding
    @Override public boolean add(E e) {
        // Add custom logic safely
        return s.add(e);
    }
    // ... other methods forward to s.method() ...
}

Java 17 (work): ⚠ Apply the book's solution

The principle is even more relevant in modern Java. If you find yourself wanting to extend a class to reuse logic, consider using Composition combined with Delegation. If you need to "decorate" a class, the Decorator Pattern (using composition) is the standard industry approach.

Java 21 (personal): ⚠ Apply the book's solution

Java 21's focus on sealed classes and records doesn't change this. In fact, if you want to prevent inheritance for security reasons, Sealed Classes (Java 17+) allow you to restrict who can extend your classes, further emphasizing that inheritance should be a deliberate, controlled choice rather than a default mechanism for code reuse.

Item 19: Design and document for inheritance or else prohibit it

🔴 Problem: Inheriting from Undesigned Classes

Inheritance violates encapsulation because subclasses depend on the internal implementation details of the superclass. If you don't explicitly document these details, you create a "fragile base class" that breaks whenever you update its internals.

🟠 If you ignore this

• Fragile Subclasses: Future changes to your class will silently break subclasses you don't even know exist.

• Constructor Hazards: If your constructors call overridable methods, subclasses will be initialized with incomplete or null data, leading to runtime failures.

• API Commitment: Once you document a "self-use" pattern or expose a protected hook, you are committed to that implementation detail forever, limiting your ability to performance-tune or refactor.

🟢 Solution

• The Golden Rule: Either design and document the class for inheritance, or explicitly prohibit it.

• Document Self-Use: Use the @implSpec Javadoc tag to explicitly detail which overridable methods are called, in what sequence, and how they affect the result.

• Provide Hooks: Expose protected members (methods/fields) only if they are necessary for subclasses to perform their tasks efficiently. Test this by writing at least three distinct subclasses.

• Safe Constructors: Never call overridable methods from constructors, clone(), or readObject(). The subclass state isn't initialized yet, so the override will likely fail or see invalid data.

• Prohibit Subclassing: If a class isn't explicitly designed for extension, mark it final or make constructors private/package-private and use static factory methods.

🔵 Why it works

By documenting "self-use" patterns, you define the "contract" for subclasses, allowing them to override methods without breaking the base class's logic. Prohibiting inheritance for concrete classes without such documentation prevents "accidental" breakage and keeps your API design clean and flexible.

☕ Code

Java

// BAD: Constructor calls an overridable method (Subclass will see null/uninitialized data)
public class Super {
    public Super() { overrideMe(); }
    public void overrideMe() { } 
}

// GOOD: Prohibit inheritance for concrete classes
public final class Utility {
    private Utility() { ... } // No public constructors
}

// GOOD: Or, eliminate "self-use" with private helper methods
public class SafeBase {
    public void operation() {
        helper(); // Private methods are safe to call from constructors
    }
    private void helper() { ... }
}

Java 17 (work): ⚠ Apply the book's solution

Use sealed classes (Java 17+) to explicitly define which classes are allowed to extend yours. This provides a "middle ground" between final and wide-open inheritance, allowing you to control the hierarchy strictly.

Java 21 (personal): ⚠ Apply the book's solution

Java 21 reinforces the use of Sealed Classes. If you find yourself wanting to allow inheritance but fearing fragility, seal your base class and permit only your known, tested implementations. If it doesn't need to be extended, keep it final or use composition (Item 18) instead.

Item 20: Prefer interfaces to abstract classes

🔴 Problem: Abstract Class Constraints

Abstract classes suffer from the "single inheritance" restriction. If you use them to define types, you force every implementation into a rigid, monolithic hierarchy. This makes it impossible for a class to adopt your type if it already extends another class, leading to bloated class hierarchies and "combinatorial explosions" of subclasses.

🟠 If you ignore this

• Rigid Hierarchies: You prevent classes from being retrofitted to your type without major refactoring.

• Combinatorial Explosion: To support all combinations of features (e.g., Singer, Songwriter, SingerSongwriter), you are forced to create an exponential number of classes.

• Reduced Reuse: Clients lose the ability to use the "wrapper class" idiom (Item 18) to augment your type, as they are forced to use inheritance.

🟢 Solution

• Favor Interfaces: Use interfaces as your primary type definition mechanism. They allow for non-hierarchical frameworks where a class can implement multiple types (mixins).

• Skeletal Implementations: Combine the best of both worlds by providing a "skeletal implementation" (an abstract class like AbstractList) alongside your interface.

• Default Methods: Use Java 8+ default methods in the interface for shared behavior, but reserve abstract classes for non-primitive interface methods that require shared state or cannot be implemented via interface defaults.

• Simulated Multiple Inheritance: If a class cannot extend your skeletal implementation, have it implement the interface and forward calls to a private inner class that does extend the skeletal implementation.

🔵 Why it works

Interfaces provide maximum flexibility. They act as "mixins" that can be added to any class, regardless of its place in the type hierarchy. Skeletal implementations offer "template" code for those who want it, without mandating inheritance for those who need to extend something else.

☕ Code

Java

// GOOD: Interface defines the type; Abstract class provides the skeletal implementation
public interface MapEntry<K, V> {
    K getKey();
    V getValue();
    // Default method for behavior that doesn't require state
    default String summary() { return getKey() + "=" + getValue(); }
}

// Skeletal implementation for complex/stateful logic
public abstract class AbstractMapEntry<K, V> implements MapEntry<K, V> {
    @Override public boolean equals(Object o) { ... }
    @Override public int hashCode() { ... }
}

Java 17 (work): ⚠ Apply the book's solution

Interfaces are more powerful than ever. With sealed interfaces, you can control the hierarchy precisely, providing the safety of an abstract class while keeping the flexibility of an interface.

Java 21 (personal): ⚠ Apply the book's solution

Continue to prioritize interfaces. If you are building APIs, use interfaces to define the contract and provide default methods for common logic. Only reach for an abstract class when you need to provide a "skeletal" implementation that requires shared private state or fields, which interfaces still cannot hold.

Item 21: Design interfaces for posterity

🔴 Problem: Default Method Fragility

While default methods allow you to add functionality to existing interfaces, they are "injected" into every implementation without the implementor's consent. This breaks the fundamental contract of many existing classes—especially wrappers, synchronized collections, and specialized implementations—which often rely on specific internal locking or state-management logic that a general-purpose default implementation cannot know about.

🟠 If you ignore this

• Silent Runtime Failures: Your interface implementation may compile perfectly but throw ConcurrentModificationException or produce corrupted data at runtime because the default method bypasses critical synchronization or safety logic.

• API Bloat: Adding methods to interfaces is effectively permanent. Once released, you are committed to that method's contract and behavior forever, regardless of how it interacts with future (or past) implementations.

• Implementation Incompatibility: You may inadvertently break third-party libraries that rely on your interface, creating a "version hell" where your updates crash user code that you never anticipated.

🟢 Solution

• Design for Posterity: Treat every interface method as a permanent commitment. Design them with extreme care, as you cannot remove or change them once released.

• Test Thoroughly: Before releasing a new interface, create at least three diverse implementations and multiple client programs to exercise the interface. This reveals flaws when they are still correctable.

• Avoid Post-Release Modification: Avoid adding methods to existing interfaces unless absolutely critical.

• Use Defaults for Boilerplate, Not Evolution: Use default methods primarily when creating a new interface to provide standard implementations (Item 20), not as a tool to retroactively "fix" or evolve existing ones.

🔵 Why it works

Interfaces are the most rigid part of a Java API. By acknowledging that default methods are an imperfect patch for interface evolution, you prioritize pre-release testing and careful design, which are the only ways to guarantee that all future implementations remain correct and robust.

☕ Code

Java

// BAD: Default method injected into an interface (like Collection)
// It works for general classes, but breaks SynchronizedCollection
default boolean removeIf(Predicate<? super E> filter) {
    // ... iterates and removes without knowing about the lock object ...
}

// GOOD: Design interfaces with multiple implementations in mind
// If a default method is risky, force the implementation to override it
// or document the implementation requirements using @implSpec.

Java 17 (work): ⚠ Apply the book's solution

The risks remain identical. Even with modern Java, a default method that ignores a synchronized or ReentrantLock strategy in a wrapper class will cause the same concurrency bugs identified in the book.

Java 21 (personal): ⚠ Apply the book's solution

Java 21 continues the trend of using default methods heavily in new interfaces (like SequencedCollection). When designing your own, always document @implSpec so that implementors understand the "self-use" requirements (Item 19) of your default method before they decide whether to override it.

Item 22: Use interfaces only to define types

🔴 Problem: Constant Interfaces (The Antipattern)

Using an interface solely to store a collection of static final constants is a misuse of the interface mechanism. An interface's purpose is to define a type (a contract for what an object does); it is not a tool for grouping implementation details or constants.

🟠 If you ignore this

• Leaky Abstractions: Your internal implementation details (which constants you use) leak into your public API, where they do not belong.

• Namespace Pollution: Any class that implements a constant interface forces those constants into the namespace of all its subclasses, cluttering their scope.

• Binary Compatibility Trap: Once a class implements a constant interface, you are stuck with it. Even if you stop using the constants, you must keep implementing the interface to maintain binary compatibility for existing clients.

• Confusing API: Users of your class may be confused as to why your class claims to "be a" PhysicalConstants (the interface name).

🟢 Solution

• Tie to the Source: If constants are strongly tied to a class (like Integer.MAX_VALUE), place them directly inside that class.

• Use Enums: If constants represent a set of fixed values (like Day.MONDAY), use an enum type.

• Use Utility Classes: For general constants, use a non-instantiable utility class (class with a private constructor).

• Leverage Static Imports: If you want to avoid qualifying constant names (e.g., PhysicalConstants.PI), use the import static facility instead of implementing an interface.

🔵 Why it works

Interfaces define behavioral contracts. By moving constants into utility classes or enums, you restore the interface to its intended purpose—defining what a client can do with an object—and keep your internal configuration details hidden.

☕ Code

Java

// BAD: Constant interface antipattern
public interface PhysicalConstants {
    static final double AVOGADROS_NUMBER = 6.022_140_857e23;
}

// GOOD: Non-instantiable utility class
public class PhysicalConstants {
    private PhysicalConstants() { } // Prevents instantiation

    public static final double AVOGADROS_NUMBER = 6.022_140_857e23;
}

// GOOD: Using static import in client code
import static com.effectivejava.science.PhysicalConstants.*;

public class Test {
    double atoms(double mols) {
        return AVOGADROS_NUMBER * mols; // No need to qualify with class name
    }
}

Java 17 (work): ⚠ Apply the book's solution

The advice holds. With the advent of modern Java, static imports have become the standard, idiomatic way to use constants from utility classes without the mess of constant interfaces.

Java 21 (personal): ⚠ Apply the book's solution

Continue to strictly avoid constant interfaces. If you have a large set of related constants, consider if they should be defined within a sealed interface or as individual records/enums depending on their role in your domain model.

Item 23: Prefer class hierarchies to tagged classes

🔴 Problem: Tagged Classes

A "tagged class" uses a field (the tag) and a switch statement to switch between different behaviors or data layouts within a single class. This is an antipattern that mimics subtyping without the benefits of the language's object-oriented features.

🟠 If you ignore this

• Boilerplate Bloat: Your code is cluttered with manual checks, switch statements, and fields that are irrelevant to most instances.

• Fragility: If you add a new "flavor," you must update every single switch statement in the class. Forget one, and your program crashes at runtime.

• Inefficiency: Instances are burdened with fields belonging to other flavors, wasting memory.

• Lack of Type Safety: The compiler cannot verify that the correct fields were initialized for the specified tag; errors are only caught at runtime.

🟢 Solution

• Use Class Hierarchies: Replace the tag with an abstract base class or interface.

• Flavor-Specific Subclasses: Create a concrete subclass for each "flavor" (e.g., Circle, Rectangle).

• Polymorphism: Define abstract methods in the root class (e.g., area()) and let each subclass provide its own implementation. This replaces the switch statement with polymorphic method dispatch.

• Natural Evolution: This structure allows you to easily add new types (e.g., Square) by simply extending the hierarchy, without modifying existing code.

🔵 Why it works

Class hierarchies move logic out of switch statements and into the classes themselves. This leverages the compiler to enforce correctness (ensuring all abstract methods are implemented), reduces memory overhead by only storing relevant fields, and provides clear, type-safe boundaries between different flavors.

☕ Code

Java

// BAD: Tagged Class (Verbose, error-prone, hard to maintain)
class Figure {
    enum Shape { RECTANGLE, CIRCLE }
    final Shape shape;
    double radius; // Unused for Rectangle
    double length, width; // Unused for Circle
    
    double area() {
        switch(shape) {
            case RECTANGLE: return length * width;
            case CIRCLE: return Math.PI * radius * radius;
            default: throw new AssertionError();
        }
    }
}

// GOOD: Class Hierarchy (Clean, extensible, type-safe)
abstract class Figure {
    abstract double area();
}

class Circle extends Figure {
    final double radius;
    Circle(double radius) { this.radius = radius; }
    @Override double area() { return Math.PI * (radius * radius); }
}

class Rectangle extends Figure {
    final double length, width;
    Rectangle(double length, double width) { 
        this.length = length; this.width = width; 
    }
    @Override double area() { return length * width; }
}

Java 17 (work): ⚠ Apply the book's solution

If you are using Java 17, use Sealed Hierarchies. A sealed class allows you to explicitly define the permitted subclasses. This gives you the exhaustiveness checking that switch statements used to provide, but with the clean, type-safe architecture of an object-oriented hierarchy.

Java 21 (personal): ⚠ Apply the book's solution

Java 21's Pattern Matching for switch combined with sealed hierarchies is the ultimate way to handle this. You can define a sealed hierarchy, and the compiler will verify that your switch patterns cover all possible subclasses, giving you the safety of a tagged class with the architectural beauty of a hierarchy.

Item 24: Favor static member classes over nonstatic

🔴 Problem: Hidden Object References

In Java, nested classes are powerful, but nonstatic member classes carry a "hidden" reference to the instance of their enclosing class. If you don't need that reference, you are wasting memory, increasing construction time, and—most dangerously—risking memory leaks by preventing the enclosing instance from being garbage collected.

🟠 If you ignore this

• Memory Leaks: The hidden reference keeps the entire enclosing object alive in memory as long as the nested class instance exists, even if the enclosing object is no longer needed.

• Performance Overhead: Every instance of a nonstatic class carries an extra pointer, adding time and space costs that accumulate in large data structures (like maps or trees).

• API Rigidity: If you expose a nonstatic member class in a public API, you are locked into that design. You cannot change it to static later without breaking backward compatibility.

🟢 Solution

• Default to static: Always add the static modifier to a member class unless it must access the enclosing instance's members.

• Analyze the "Is-Isolated" Test: If an instance of your nested class can exist logically on its own, it should be a static member class.

• Reserve Nonstatic for Adapters: Use nonstatic member classes only when the nested class acts as an adapter (like an Iterator for a List or a KeySet for a Map) that needs to operate on the state of the specific enclosing instance.

• Keep Anonymous/Local Short: Use anonymous classes only for very small, one-off objects (typically < 10 lines). Since Java 8, prefer lambdas for function objects.

🔵 Why it works

static member classes are effectively top-level classes that just happen to be scoped inside another class. They have no overhead, no hidden references, and provide cleaner memory management. By being explicit, you ensure that only the classes that truly need the context of an enclosing instance pay the cost of carrying a reference to it.

☕ Code

Java

// BAD: Nonstatic member class (Hidden reference to enclosing Map)
private class Entry { ... } // Entry instance holds a reference to the Map!

// GOOD: Static member class (No overhead)
private static class Entry<K, V> {
    final K key;
    final V value;
    // No hidden reference to Map instance here
}

// GOOD: Nonstatic member class (Adapter pattern)
// Iterator needs to see the internal state of the specific MySet instance
public Iterator<E> iterator() {
    return new MyIterator(); // Automatically associated with the enclosing instance
}

Java 17/21 (modern context): ⚠ Apply the book's solution

The rules have not changed. While modern Java provides concise syntax (lambdas, records), the underlying mechanism of member classes remains the same. If you are implementing a complex data structure in Java 21, always use private static classes for internal nodes/entries to minimize memory footprint and avoid subtle leaks.

To help you internalize this for your interviews, would you like me to structure these nesting rules into a comparison table?

Item 25: Limit source files to a single top-level class

🔴 Problem: Multiple Top-Level Classes

Defining more than one top-level class (or interface) in a single source file is an invitation to non-deterministic behavior. Java's compiler is susceptible to the order in which files are passed to it, which can cause it to pick different class definitions for the same name depending on what it encounters first.

🟠 If you ignore this

• Non-Deterministic Builds: The behavior of your program can change based solely on the order of file arguments passed to javac or the order in which your build system processes them.

• Maintenance Headaches: It becomes trivial to accidentally create multiple definitions of the same class (e.g., in a separate file), leading to cryptic compilation errors that are difficult to trace.

• Fragility: You lose the ability to guarantee a consistent, reproducible build environment.

🟢 Solution

• One File, One Class: Strictly limit each source file to exactly one top-level class or interface.

• Use Static Member Classes: If you have helper classes that are only used by a single main class, nest them as static member classes (Item 24) within that main class.

• Encapsulation: By using private static member classes, you reduce the class's visibility to only the enclosing class, which is a cleaner design than having multiple public or package-private classes floating around at the top level.

🔵 Why it works

By enforcing a one-to-one mapping between source files and top-level classes, you make it impossible for the compiler to encounter multiple definitions for the same name. It guarantees that your build process is predictable and that every reference to a class resolves to the same source file every time.

☕ Code

Java

// BAD: Two top-level classes in one file
// Potential for "potpie" vs "pancake" ambiguity depending on compilation order
class Utensil { static final String NAME = "pan"; }
class Dessert { static final String NAME = "cake"; }

// GOOD: Single top-level class with private static member classes
public class Test {
    public static void main(String[] args) {
        System.out.println(Utensil.NAME + Dessert.NAME);
    }
    
    // Encapsulated and clearly defined
    private static class Utensil { static final String NAME = "pan"; }
    private static class Dessert { static final String NAME = "cake"; }
}

Java 17/21 (modern context): ⚠ Apply the book's rule

This rule remains a fundamental best practice for Java development. Even with modern build systems like Maven or Gradle, which usually manage file order for you, keeping one class per file is the professional standard that ensures your project remains readable, portable, and immune to hidden compilation-order bugs.

Would you like to move on to Chapter 5 (Generics), or is there another item in Chapter 4 you'd like to review?