JDK-8294155 : Exception thrown before awaitAndCheck hangs PassFailJFrame
  • Type: Bug
  • Component: client-libs
  • Affected Version: 19
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2022-09-22
  • Updated: 2025-03-20
  • Resolved: 2025-02-17
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 11 JDK 17 JDK 21 JDK 24 JDK 25 JDK 8
11.0.28-oracleFixed 17.0.16-oracleFixed 21.0.8-oracleFixed 24.0.2Fixed 25 b11Fixed 8u461Fixed
Related Reports
Cloners :  
JDK-8349845 - PassFailJFrame hangs if an exception thrown before awaitAndCheck
Relates :  
JDK-8293830 - ☂ Redesign Manual Test Framework: PassFailJFrame
Relates :  
JDK-8283712 - Create a manual test framework class
Description
If an exception is thrown before awaitAndCheck is called, the test will hang eventually. Clicking the Pass/Fail buttons doesn't close the UI since it's inside awaitAndCheck. This needs to be addressed when redesigning the framework.
Comments
Fix request [21u,17u] I backport this for parity with 21.0.8-oracle,17.0.16-oracle. No risk, only a test change. Clean backport. Succesfully ran some tests using PFJF, SAP nightly testing passed.
20-03-2025
A pull request was submitted for review. Branch: master URL: https://git.openjdk.org/jdk21u-dev/pull/1522 Date: 2025-03-18 20:14:00 +0000
18-03-2025
A pull request was submitted for review. Branch: master URL: https://git.openjdk.org/jdk17u-dev/pull/3381 Date: 2025-03-18 20:14:18 +0000
18-03-2025
A pull request was submitted for review. Branch: master URL: https://git.openjdk.org/jdk24u/pull/98 Date: 2025-03-03 19:07:19 +0000
03-03-2025
Fix request for 24u This fix improves handling of exception during PassFailJFrame initialisation. Only manual tests are affected. Risk: Low
27-02-2025
Changeset: 906358d3 Branch: master Author: Alexey Ivanov <aivanov@openjdk.org> Date: 2025-02-17 13:13:15 +0000 URL: https://git.openjdk.org/jdk/commit/906358d3a14ce755fec771f0a6bb856b3a8f3297
17-02-2025
A pull request was submitted for review. Branch: master URL: https://git.openjdk.org/jdk/pull/23564 Date: 2025-02-11 16:17:13 +0000
11-02-2025
As an example, if I modify test/jdk/java/awt/font/TextLayout/ArabicBox.java to throw an exception from TextPanel constructor: ======= diff --git a/test/jdk/java/awt/font/TextLayout/ArabicBox.java b/test/jdk/java/awt/font/TextLayout/ArabicBox.java index e03c4cf918e..08b94362180 100644 --- a/test/jdk/java/awt/font/TextLayout/ArabicBox.java +++ b/test/jdk/java/awt/font/TextLayout/ArabicBox.java @@ -82,6 +82,7 @@ private TextPanel(Font font) { setBackground(Color.white); setFont(font); setPreferredSize(new Dimension(300, 150)); + throw new IllegalArgumentException("Oops!"); } @Override ======= The following stack trace is produced: Exception in thread "main" java.lang.reflect.InvocationTargetException at java.desktop/java.awt.EventQueue.invokeAndWait(EventQueue.java:1371) at java.desktop/java.awt.EventQueue.invokeAndWait(EventQueue.java:1346) at java.desktop/javax.swing.SwingUtilities.invokeAndWait(SwingUtilities.java:1480) at PassFailJFrame.invokeOnEDT(PassFailJFrame.java:556) at PassFailJFrame.<init>(PassFailJFrame.java:493) at PassFailJFrame$Builder.build(PassFailJFrame.java:1791) at ArabicBox.main(ArabicBox.java:69) Caused by: java.lang.IllegalArgumentException: Oops! at ArabicBox$TextPanel.<init>(ArabicBox.java:85) at ArabicBox.createPanel(ArabicBox.java:74) at ArabicBox.lambda$main$0(ArabicBox.java:68) at PassFailJFrame.createUI(PassFailJFrame.java:609) at PassFailJFrame.lambda$new$1(PassFailJFrame.java:493) at java.desktop/java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:308) at java.desktop/java.awt.EventQueue.dispatchEventImpl(EventQueue.java:773) at java.desktop/java.awt.EventQueue$4.run(EventQueue.java:720) at java.desktop/java.awt.EventQueue$4.run(EventQueue.java:714) at java.base/java.security.AccessController.doPrivileged(AccessController.java:400) at java.base/java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:87) at java.desktop/java.awt.EventQueue.dispatchEvent(EventQueue.java:742) at java.desktop/java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:203) at java.desktop/java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:124) at java.desktop/java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:113) at java.desktop/java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:109) at java.desktop/java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:101) at java.desktop/java.awt.EventDispatchThread.run(EventDispatchThread.java:90) And then the test continues to run but no UI is shown. You have to kill the Java process. (As mentioned above, it's not a problem when the test is run with jtreg.)
11-02-2025
This is not a problem when the test is run with jtreg. If an exception is thrown after PassFailJFrame is constructed but before awaitAndCheck() is call, the main thread will exit, and jtreg will shut down the JVM running the test. Yet it would still be nice to handle such a situation gracefully when a test is run as stand-alone app.
11-02-2025
This issue is somewhat mitigated by the Builder pattern introduced in JDK-8294535, yet not completely. PassFailJFrame.Builder.build() could catch exceptions and dispose of all the registered windows before propagating the exception. Disposing of the windows will allow AWT to shut down the toolkit thread, which, in its turn, will allow the JVM to exit cleanly. When a test is run with jtreg, it shouldn't hang because jtreg shuts down the JVM after the main thread exists.
10-12-2024