Bug ID: JDK-8289616 Drop use of Thread.stop in AppContext

Type: Sub-task
Component: client-libs
Sub-Component: java.awt

Priority: P3
Status: Open
Resolution: Unresolved

Submitted: 2022-07-02
Updated: 2022-08-13

JDK 20
20Unresolved

sun.awt.AppContext.dispose uses Thread.stop to "stop" all threads in a thread group that don't response to Thread.interrupt within 1s. This code will break once Thread.stop has been degraded to throw UOE unconditionally.

java/awt/AppContext/ApplicationThreadsStop/ApplicationThreadsStop.java is one test that seems to exercise this code.

A pull request was submitted for review. URL: https://git.openjdk.org/jdk/pull/9863 Date: 2022-08-12 20:14:27 +0000

12-08-2022

The following (open) tests fail if AppContext.dispose() is removed - obviously they fail compilation but on examination I expect they all need it to function as well java/awt/AppContext/ApplicationThreadsStop/ApplicationThreadsStop.java javax/swing/plaf/metal/MetalUtils/bug6190373.java javax/swing/system/6799345/TestShutdown.java sun/awt/AppContext/8012933/Test8012933.java prrace@prrmac jdk % (appcontext)

06-08-2022

The problem is Thread.stop() but also I notice ThreadGroup.destroy() There really is NO replacement for Thread.stop() for code which doesn't have a way to jump on that thread and stop it, or have a flag to stop it. So since it is terminally deprecated we just need to stop calling it. And the same goes for ThreadGroup.destroy(). Per Alan Batemean it was degraded to be a no-op in Java 19. AppContext.dispose() is no longer called from anywhere in JDK code. In JDK8u and earlier was called from deploy stack code which used it for Applets and Webstart but those don't exist anymore. So it could be that we 1) just remove the blocks of code in dispose() which are deprecated for removal This is Thread.stop() and also the call to ThreadGroup.destroy(); or, 2) Completely hollow out the method, or 3) Completely remove the method #1 would be what you'd do if this was still used and you needed to at least clean up what you can #2 would mean at least no caller would get a NoSuchMethodError .. but what's the point ? I favour #3 because then we'll definitely find out if anything is calling it ! We could go a little further and delete the code that creates additional AppContext instances because it is obsolete. Note that we this has some special case code for AWT embedded in an FX application so long as the current thread group has a parent .. In this case we do not ever create the mainAppContext .. it is a single appcontext for use by FX So not a multi-app context case. I've located the bug which added it which was for when running FX in a webstart environment changeset: 7773:e76b1568d002 user: leonidr date: Fri Aug 02 15:42:04 2013 +0400 summary: 8021381: JavaFX scene included in Swing JDialog not starting from Web Start added (just) these lines + } else if (System.getProperty("javafx.version") != null && + threadGroup.getParent() != null) { + // Swing inside JavaFX case + SunToolkit.createNewAppContext(); So we probably can get rid of that OR leave it for another day but either way get rid of all code that creates > 1 appcontext Note also this code jdk.unsupported.desktop which is called by FX Swing interop (that's the only reason this exists) is what would need it : public class SwingInterOpUtils { /** * Constructs a {@code SwingInterOpUtils}. */ public SwingInterOpUtils() {} public static void postEvent(Object target, java.awt.AWTEvent e) { AppContext context = SunToolkit.targetToAppContext(target); if (context != null) { SunToolkit.postEvent(context, e); } } ... I think leaving the FX related code in for now is probably the easiest just to avoid having to test FX The much bigger question of completely purging AppContext is for later - AppContext is quite pervasive even if not useful anymore.

05-08-2022