finalize()

// ── How finalize() worked (historical — removed in Java 21) ──────────
@Deprecated(since="9", forRemoval=true)  // deprecated in Java 9
public class LegacyResource {

    private long nativeHandle;

    public LegacyResource() {
        this.nativeHandle = allocateNativeResource();
    }

    // Called by the JVM finaliser thread at some undefined future time
    // (or possibly never, if the JVM exits)
    @Override
    protected void finalize() throws Throwable {
        try {
            if (nativeHandle != 0) {
                releaseNativeResource(nativeHandle);
                nativeHandle = 0;
            }
        } finally {
            super.finalize();
        }
    }

    private native long allocateNativeResource();
    private native void releaseNativeResource(long handle);
}

// ── Why finalize() was fundamentally broken ───────────────────────────
//
// Problem 1: Non-deterministic timing
//   Object becomes unreachable → GC discovers → added to finaliser queue
//   Finaliser thread processes queue → finalize() called → THEN collectable
//   Time from unreachable to finalize(): milliseconds to NEVER
//   File handles, DB connections held open indefinitely
//
// Problem 2: Objects could be resurrected
//   finalize() can store 'this' in a static field — object becomes reachable again!
//   Object escapes collection in one GC cycle, must reach finalization again
//   finalize() called at most ONCE per object — second unreachable cycle
//   has no safety net at all
//
// Problem 3: No ordering guarantees
//   A's finalize() may see B in an inconsistent state
//   B's finalize() may not have run yet when A's finalize() runs
//   Cannot safely use other finalizable objects from finalize()
//
// Problem 4: Exceptions in finalize() are silently ignored
//   if (condition) throw new RuntimeException("cleanup failed");
//   The exception is swallowed — cleanup partially executed, no notification
//
// Problem 5: Performance impact
//   Objects with non-trivial finalize() require an extra GC cycle to collect
//   (survive one cycle to be queued, survive another to be actually collected)
//   Long-lived objects with finalize() accumulate in old gen
//   Finaliser thread can become a bottleneck under heavy allocation

// ── Demonstration of finalize() problems ────────────────────────────

// Problem: Resurrection — finalize() saves 'this', preventing collection
public class ResurrectionExample {

    static ResurrectionExample lastInstance;

    @Override
    protected void finalize() {
        System.out.println("finalize() called — but I'm escaping!");
        lastInstance = this;   // RESURRECTION — object becomes reachable again
        // Now the object survives this GC cycle
        // Next time it becomes unreachable, finalize() is NOT called again
        // It will be silently collected — the "safety net" is gone
    }
}

// Problem: Exception swallowed — incomplete cleanup with no notification
public class SilentFailure {

    @Override
    protected void finalize() {
        System.out.println("Starting cleanup...");
        throw new RuntimeException("Cleanup failed!");
        // This exception is SILENTLY SWALLOWED by the JVM
        // Cleanup is incomplete, but no one is notified
        System.out.println("This never runs");
    }
}

// Problem: Performance — two GC cycles to collect finalizable objects
// Normal object:           unreachable → COLLECTED (1 cycle)
// Finalizable object:      unreachable → queued → finalize() → COLLECTED (2 cycles)
//
// In HotSpot, finalizable objects:
// - Cannot be collected in the same young GC they become unreachable
// - Must survive to be placed on the finaliser queue
// - Survive long enough to be promoted to old gen frequently
// - Old gen collection is much more expensive than young gen

// ── Why explicitly removed in Java 21 ─────────────────────────────────
// JEP 421: Deprecate Finalization for Removal (Java 18)
// Reasoning:
// 1. Replacement mechanisms (try-with-resources, Cleaner) have existed since Java 7/9
// 2. finalize() creates real security vulnerabilities in serialisation
// 3. Performance cost measurable and significant
// 4. Almost no legitimate use cases exist that cannot be better served by alternatives
// 5. Strong backward compatibility commitment delayed removal for 10+ years

// ── Cleaner — the modern replacement for finalize() ─────────────────
import java.lang.ref.Cleaner;

public class NativeResourceWrapper implements AutoCloseable {

    // One Cleaner per application or library — shared, thread-safe
    private static final Cleaner CLEANER = Cleaner.create();

    // ── State class — holds only the native resource info ─────────────
    // CRITICAL: must be static (or non-inner) — must NOT hold a reference
    // to NativeResourceWrapper, or the wrapper could never be collected
    private static class CleanupState implements Runnable {
        private long nativeHandle;

        CleanupState(long handle) {
            this.nativeHandle = handle;
        }

        @Override
        public void run() {
            // Called by Cleaner thread when NativeResourceWrapper is GC'd
            // OR when clean() is called explicitly
            if (nativeHandle != 0) {
                System.out.println("Cleaning up handle: " + nativeHandle);
                releaseNativeHandle(nativeHandle);
                nativeHandle = 0;
            }
        }

        private static native void releaseNativeHandle(long handle);
    }

    private final long              nativeHandle;
    private final Cleaner.Cleanable cleanable;

    public NativeResourceWrapper() {
        this.nativeHandle = allocateNativeHandle();
        CleanupState state = new CleanupState(nativeHandle);
        // Register: when THIS object becomes unreachable, run state.run()
        this.cleanable = CLEANER.register(this, state);
        // Note: state must not reference 'this' — no reference to NativeResourceWrapper
    }

    public void doWork() {
        // ... use nativeHandle ...
    }

    @Override
    public void close() {
        cleanable.clean();   // explicit cleanup — also cancels the GC-triggered cleanup
    }

    private static native long allocateNativeHandle();
}

// ── Usage — try-with-resources is ALWAYS preferred ─────────────────────
try (NativeResourceWrapper resource = new NativeResourceWrapper()) {
    resource.doWork();
}   // close() called → clean() called → immediate cleanup

// Cleaner is the safety net if caller forgets close():
NativeResourceWrapper leakedResource = new NativeResourceWrapper();
leakedResource = null;   // no close() called
// GC eventually detects unreachable → phantom reference enqueued
// → Cleaner thread calls CleanupState.run() → native handle freed
// (timing not guaranteed, but will happen before OOM)