--- old/src/java.base/share/classes/java/lang/doc-files/threadPrimitiveDeprecation.html 2017-08-18 15:03:10.766796505 -0700 +++ new/src/java.base/share/classes/java/lang/doc-files/threadPrimitiveDeprecation.html 2017-08-18 15:03:10.558787407 -0700 @@ -1,3 +1,4 @@ + - Java Thread Primitive Deprecation @@ -30,7 +30,7 @@

Java Thread Primitive Deprecation

-
+

Why is Thread.stop deprecated?

Because it is inherently unsafe. Stopping a thread causes it to unlock all the monitors that it has locked. (The monitors are @@ -45,7 +45,7 @@ no warning that his program may be corrupted. The corruption can manifest itself at any time after the actual damage occurs, even hours or days in the future.

-
+

Couldn't I just catch the ThreadDeath exception and fix the damaged object?

In theory, perhaps, but it would vastly complicate the @@ -61,7 +61,7 @@ it succeeded. The code to ensure this would be quite complex. In sum, it just isn't practical. -

+

What about Thread.stop(Throwable)?

In addition to all of the problems noted above, this method may be used to generate exceptions that its target thread is unprepared @@ -76,7 +76,7 @@ Thread.currentThread().stop(t); } -

+

What should I use instead of Thread.stop?

Most uses of stop should be replaced by code that simply modifies some variable to indicate that the target thread @@ -84,7 +84,7 @@ regularly, and return from its run method in an orderly fashion if the variable indicates that it is to stop running. To ensure prompt communication of the stop-request, the variable must be -volatile (or access to the variable must be +volatile (or access to the variable must be synchronized).

For example, suppose your applet contains the following start, stop and run @@ -131,7 +131,7 @@ } } -

+

How do I stop a thread that waits for long periods (e.g., for input)?

That's what the Thread.interrupt method is for. The @@ -159,7 +159,7 @@ This ensures that the Thread will reraise the InterruptedException as soon as it is able. -

+

What if a thread doesn't respond to Thread.interrupt?

In some cases, you can use application specific tricks. For @@ -172,7 +172,7 @@ cases include deliberate denial-of-service attacks, and I/O operations for which thread.stop and thread.interrupt do not work properly.

-
+

Why are Thread.suspend and Thread.resume deprecated?

Thread.suspend is inherently deadlock-prone. If the @@ -182,7 +182,7 @@ would resume the target thread attempts to lock this monitor prior to calling resume, deadlock results. Such deadlocks typically manifest themselves as "frozen" processes.

-
+

What should I use instead of Thread.suspend and Thread.resume?

As with Thread.stop, the prudent approach is to @@ -274,7 +274,7 @@ }

In the absence of explicit synchronization, -threadSuspended must be made volatile to ensure +threadSuspended must be made volatile to ensure prompt communication of the suspend-request.

The resulting run method is: 
@@ -302,17 +302,17 @@
 be safely "stopped" or "suspended"?
 Yes, it's reasonably straightforward. The one subtlety is that the
 target thread may already be suspended at the time that another
-thread tries to stop it. If the stop method merely sets
-the state variable (blinker) to null, the target thread
+thread tries to stop it. If the stop method merely sets
+the state variable (blinker) to null, the target thread
 will remain suspended (waiting on the monitor), rather than exiting
 gracefully as it should. If the applet is restarted, multiple
 threads could end up waiting on the monitor at the same time,
 resulting in erratic behavior.
-
To rectify this situation, the stop method must ensure
+
To rectify this situation, the stop method must ensure
 that the target thread resumes immediately if it is suspended. Once
 the target thread resumes, it must recognize immediately that it
 has been stopped, and exit gracefully. Here's how the resulting
-run and stop methods look:

+run and stop methods look:

 
     public void run() {
         Thread thisThread = Thread.currentThread();
@@ -335,18 +335,18 @@
         notify();
     }
 

-If the stop method calls Thread.interrupt, as
-described above, it needn't call notify as well, but it
+If the stop method calls Thread.interrupt, as
+described above, it needn't call notify as well, but it
 still must be synchronized. This ensures that the target thread
 won't miss an interrupt due to a race condition.
-

+

 
What about Thread.destroy?

 Thread.destroy was never implemented and has been
 deprecated. If it were implemented, it would be deadlock-prone in
 the manner of Thread.suspend. (In fact, it is roughly
 equivalent to Thread.suspend without the possibility
 of a subsequent Thread.resume.)
-

+

 
Why is Runtime.runFinalizersOnExit
 deprecated?

 Because it is inherently unsafe. It may result in finalizers being