JDK-8136858 : Examine the usage of ThreadGroup.stop() in sun.awt.AppContext
  • Type: Bug
  • Component: client-libs
  • Sub-Component: java.awt
  • Affected Version: 9
  • Priority: P2
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2015-09-21
  • Updated: 2015-11-12
  • Resolved: 2015-10-12
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 9
9 b89Fixed
Related Reports
Blocks :  
JDK-7067728 - Remove stopThread RuntimePermission from the default java.policy
Description
see JDK-8136403 - Thread.stop is unsafe, has been deprecated for many years, and should not be needed here.
Comments
Sergey, I re-opened this bug. I hope you will consider, at least, wrapping the usage of ThreadGroup.stop in a doPriv block. That way when JDK-7067728 removes "stopThread" permission from the default policy file, AppContext will not be impacted.
01-10-2015
Since default permission is changed, I think that privileged block is a right thing.
30-09-2015
The appcontext class maintain the application specific information, when appcontext is disposed we must try to destroy all application threads and threadgroups. To destroy them we need to stop all threads, because otherwise a destroy() method will throw an exception. Yes the stop() method can be ignored, but there are no other ways to force the kill of the thread other than stop+destroy. Thread.interrupt is not sufficient for such use cases, it usually is ignored if the thread has no code with throw InterruptedException, and isInterruped flag is usually ignored. This is a usual case when the application doing some heavy rendering should be stopped quickly, because some native things like browser or external container are disposed.
30-09-2015
Reopening. ThreadGroup.stop has been deprecated for more than a decade. It is restricting, in other areas, to have this dependency on stop(). It is for this reason this bug has been filed. The extra step of calling ThreadGroup.stop() makes no guarantees that all threads in the group will be stopped. For example, you can catch Throwable and ignore it. Thread.interrupt should be sufficient. From threadPrimitiveDeprecation.html [1]: What if a thread doesn't respond to Thread.interrupt? In some cases, you can use application specific tricks. For example, if a thread is waiting on a known socket, you can close the socket to cause the thread to return immediately. Unfortunately, there really isn't any technique that works in general. It should be noted that in all situations where a waiting thread doesn't respond to Thread.interrupt, it wouldn't respond to Thread.stop either. Such cases include deliberate denial- of-service attacks, and I/O operations for which thread.stop and thread.interrupt do not work properly. [1] http://docs.oracle.com/javase/7/docs/technotes/guides/concurrency/threadPrimitiveDeprecation.html
30-09-2015
The appcontext code use 3 steps to dispose itself. - interrupt the threads. This usually is ignored by the threads - stop the thread. This causes an error to be thrown in the thread, which in some cases can be catch and log. - destroy the thread. Note that threadgroup.destroy has this in specification: * Destroys this thread group and all of its subgroups. This thread * group must be empty, indicating that all threads that had been in * this thread group have since stopped. So I do not see a reason why this call should be removed.
23-09-2015