Why is an enum often the best way to implement a singleton compared to a private-constructor class?

## What is a singleton? A **singleton** is a class intended to have exactly one instance for the whole program, accessed from a global point. Think of a single configuration registry or a single logging hub. ## The traditional implementation: private constructor ```java public final class Settings { private static final Settings INSTANCE = new Settings(); private Settings() { } public static Settings getInstance() { return INSTANCE; } } ``` The private constructor stops outside code from calling `new Settings()`, and the static `INSTANCE` is created once when the class is initialized (which the JVM does in a thread-safe way). This works — but it has two well-known holes. ### Hole 1: Reflection **Reflection** is Java's ability to inspect and invoke members at runtime, including private ones. An attacker (or careless code) can do: ```java Constructor<Settings> c = Settings.class.getDeclaredConstructor(); c.setAccessible(true); // bypass 'private' Settings second = c.newInstance(); // a SECOND instance! ``` Now there are two `Settings`, breaking the singleton guarantee. To defend, the private constructor must throw if `INSTANCE` already exists — extra code you have to remember. ### Hole 2: Serialization If the singleton implements `Serializable`, **deserialization** creates a brand-new object each time you read it back, again producing duplicates. To defend, you add a `readResolve()` method returning the canonical instance — more boilerplate that's easy to forget. ## The enum singleton An `enum` is a special class whose instances are a fixed set of named constants, created once by the JVM. A single-constant enum *is* a singleton: ```java public enum Settings { INSTANCE; private int retries = 3; public int getRetries() { return retries; } } // use: Settings.INSTANCE.getRetries(); ``` Why this is better: - **Reflection-proof:** the reflection API specifically forbids creating enum instances — `Constructor.newInstance` on an enum throws `IllegalArgumentException("Cannot reflectively create enum objects")`. Hole 1 closed by the language. - **Serialization-safe:** enums have built-in special handling; deserialization always yields the existing constant, never a copy. Hole 2 closed for free — no `readResolve` needed. - **Thread-safe and lazy-ish:** the constant is initialized once on class initialization, guarded by the JVM. - **Concise:** no static accessor, no guard code. *Effective Java* (Item: "Enforce the singleton property with a private constructor or an enum type") concludes the single-element enum is usually the best approach. ## When the enum approach does NOT fit An enum already extends `java.lang.Enum` implicitly, and Java has no multiple inheritance of classes, so **an enum singleton cannot extend another class** (it *can* implement interfaces). If your singleton must inherit from a specific base class, the enum is out; you'd use a private-constructor class with the reflection guard and `readResolve` written by hand. More broadly, in modern applications the singleton *pattern* is often replaced by a **dependency-injection container** (Spring, etc.) that creates and shares a single instance ("singleton scope") for you — giving the one-instance benefit without global static state, and keeping the class testable (you can inject a different instance/mock in tests). Hard-coded singletons (enum or static) are notoriously hard to substitute in unit tests, which is the main reason to prefer DI for application services and reserve the enum singleton for truly stateless, universal utilities.