How does Java's finalize() differ from a C++ destructor, and why doesn't Java have deterministic destructors?

## Two different memory models To compare the two, start with how each language manages memory. **C++** uses *manual / scope-based* memory management. Object **lifetime** is deterministic: - A **stack object** (a local variable) is destroyed the instant control leaves its scope — its **destructor** (`~T()`) runs right there. - A **heap object** (made with `new`) is destroyed exactly when you call `delete`. Because the destruction *moment* is known, C++ has the **RAII** idiom (*Resource Acquisition Is Initialization*): acquire a resource (file, lock, memory) in the constructor and release it in the destructor. Cleanup then happens automatically and *deterministically* as objects go out of scope — even when exceptions unwind the stack. ```cpp { std::ifstream f("data.txt"); // opens // ... use f } // f's destructor runs HERE, closing the file deterministically ``` **Java** uses *automatic* memory management via a **garbage collector (GC)**. You never `delete`. The GC frees an object's memory at *some unspecified later time* after the object becomes **unreachable**. There is no defined moment of death, so there is **no place to hang a deterministic destructor**. ## What finalize() is — and why it's a poor destructor `finalize()` (inherited from `Object`) was Java's attempt to provide a destructor-like hook: the GC would call it once before reclaiming the object. But because it's bolted onto GC, it inherits all the GC's non-determinism: | Aspect | C++ destructor | Java finalize() | |---|---|---| | When it runs | Deterministic (scope exit / delete) | Whenever the GC gets to it — unspecified | | Guaranteed to run? | Yes | No (may never run, e.g. at JVM exit) | | How many times | Exactly once | At most once (can be skipped after resurrection) | | Thread | The thread doing the destruction | A separate finalizer thread | | Exceptions | Propagate (with care) | Swallowed; abort cleanup | | Status | Core idiom (RAII) | Deprecated (Java 9) / for removal (JEP 421) | So `finalize()` is at best a *pseudo-destructor*: same intent, none of the guarantees. ## Why Java deliberately has no deterministic destructor Deterministic destruction requires knowing precisely when each object dies. A tracing garbage collector intentionally *doesn't* track that per-object — it periodically finds unreachable objects in bulk and frees them, which is what lets it be efficient and relieves the programmer of manual `delete`. Adding deterministic destructors would mean reference counting every object (with cycle problems and overhead) — a different memory model. Java chose GC + an explicit, programmer-driven cleanup idiom instead. ## The Java analogue of RAII: try-with-resources Java's real answer to RAII is **try-with-resources** over the **`AutoCloseable`** interface. You put cleanup in `close()`; the compiler guarantees `close()` runs at the end of the `try` block, in reverse order of acquisition, even on exception (with suppressed exceptions attached). This gives the *deterministic* cleanup C++ gets from destructors — just at a syntactically explicit point rather than implicit scope exit: ```java try (var f = new BufferedReader(new FileReader("data.txt"))) { // ... use f } // f.close() runs HERE, deterministically ``` For resources the GC can't see (**native memory**), you can additionally register a **`Cleaner`** as a *non-deterministic* safety net for callers who forget to close — but it is a backstop, not a destructor. ## Summary - C++ destructors are deterministic (scope/`delete`) → enable RAII. - Java's GC means no deterministic death point → `finalize()` is only a GC-timed pseudo-destructor and is deprecated. - Use **try-with-resources + AutoCloseable** as Java's RAII; add a **Cleaner** only as a backstop for native resources.