Why Java’s Thread.stop() Was Finally Removed in JDK 26 – What It Means for You

JDK 26 Removes Thread.stop()

On 17 March 2026 JDK 26 was released and the long‑deprecated Thread.stop() method was permanently removed. The method was considered the most dangerous API in Java because it could leave objects in an inconsistent state.

What JDK‑8368226 Changed

The change JDK‑8368226 deletes java.lang.Thread.stop() from the JDK source, bytecode and runtime.

Code that calls Thread.stop() no longer compiles.

Existing compiled code running on JDK 26 throws NoSuchMethodError instead of the previous UnsupportedOperationException.

Historical Background (the “black history” of Thread.stop())

1998 – JDK 1.2 marks Thread.stop() as @Deprecated.

2004 – Official documentation explains why the method is unsafe.

2022 – JDK 18 marks it with @Deprecated(forRemoval = true), starting the removal countdown.

2023 – JDK 20 changes the runtime behavior to always throw UnsupportedOperationException.

2026 – JDK 26 completely removes the method.

Why Thread.stop() Is Dangerous

The official documentation summarizes: This method is inherently unsafe. When invoked two fatal actions occur:

It immediately throws a ThreadDeath error at any point in the thread’s run() method, including inside catch or finally blocks.

It forcibly releases all monitors held by the thread, potentially leaving shared objects in an inconsistent state.

Example: a bank transfer that deducts a balance, sleeps, then logs the transaction. If stop() is called during sleep, the balance is deducted but the transaction is never recorded, and the lock is released, exposing a corrupted object to other threads.

Why Catching ThreadDeath Doesn’t Help

Catching ThreadDeath is practically impossible because the error can be thrown at any point, requiring cleanup logic in every synchronized block and method. Cleanup code itself may trigger another ThreadDeath, leading to recursive handling that is infeasible. Moreover, ThreadDeath is an Error, not an Exception, so it often terminates the thread silently without a stack trace.

Modern Ways to Stop Threads

Solution 1: Cooperative Interruption

public class SafeStop {
    public static void main(String[] args) throws InterruptedException {
        Thread worker = new Thread(() -> {
            while (!Thread.currentThread().isInterrupted()) {
                try {
                    doWork();
                } catch (InterruptedException e) {
                    System.out.println("Received interrupt, exiting...");
                    cleanup();
                    break;
                }
            }
        });
        worker.start();
        Thread.sleep(1000);
        worker.interrupt(); // graceful stop request
    }
}

Solution 2: Volatile Flag (Recommended)

public class VolatileStop {
    private volatile boolean running = true;
    public void stop() { running = false; }
    public void run() {
        while (running) {
            doWork();
        }
        cleanup();
    }
}

Solution 3: Structured Concurrency (JDK 21+)

try (var scope = new StructuredTaskScope.ShutdownOnFailure()) {
    scope.fork(() -> doTask1());
    scope.fork(() -> doTask2());
    scope.join();
    scope.throwIfFailed();
} // all subtasks are automatically and safely stopped

Impact on Existing Projects and Migration Advice

Impact Assessment

Direct calls to Thread.stop() will fail to compile and must be replaced.

Reflective calls will throw NoSuchMethodError at runtime.

Legacy libraries that still use the method may need updates or workarounds.

Migration Steps

Search the entire codebase for .stop() invocations.

Replace them with interrupt() (or a volatile flag) and add cooperative checks.

Test edge cases to ensure resources are cleaned up correctly after interruption.

Upgrade third‑party dependencies to versions compatible with JDK 26.

Temporary Workarounds

Run the application on JDK 25 (LTS) if immediate migration is impossible.

Use bytecode manipulation tools (e.g., ASM) to redirect stop() calls to a custom safe‑stop implementation.

Java’s Technical Debt Cleanup

The removal of Thread.stop() is part of a broader effort to eliminate legacy APIs that were designed decades ago and no longer fit modern, secure, and performant computing environments. Recent JDK releases have also removed the Applet API, Security Manager, and 32‑bit Windows support, reflecting systematic pruning of outdated features.

References

OpenJDK JDK 26 Release Notes – https://jdk.java.net/26/release-notes Java documentation “Why Are Thread.stop, Thread.suspend and Thread.resume Deprecated?”

JDK bug tracker –

https://bugs.openjdk.org/browse/JDK-8368226