On Tue, 9 Jun 2026 10:25:00 GMT, Arno Zeller <[email protected]> wrote:
>> The doInBackground working loop is left because of the loop condition >> (!Thread.currentThread().isInterrupted()) - this will not clear the >> interrupted status of the thread and the Thread.sleep at line 63 will throw >> an InterruptedException directly. >> I suggest to change two things: >> No longer check the !Thread.currentThread().isInterrupted() but rely only on >> the Thread.sleep to throw an InterrutedException. >> And using a countdown latch instead of a sleep to ensure that we really >> entered the loop before we do cancel the worker. >> >> --------- >> - [x] I confirm that I make this contribution in accordance with the >> [OpenJDK Interim AI Policy](https://openjdk.org/legal/ai). > > Arno Zeller has updated the pull request incrementally with one additional > commit since the last revision: > > Add timeout to CountDownLatch and use Utils.adjustTimeout. test/jdk/javax/swing/SwingWorker/TestDoneBeforeDoInBackground.java line 129: > 127: }); > 128: worker.execute(); > 129: if (!workerStarted.await(5 * WAIT_TIME, TimeUnit.MILLISECONDS)) { I missed this earlier, but replacing `sleep` with `await` changed the workflow significantly: Previously, the sleep after `worker.execute()` gave SwingWorker’s async `STARTED` notification time to reach the EDT before cancellation. Now the latch only confirms that `doInBackground()` has started. Cancelling immediately after that can race ahead of the `STARTED` listener. The test should wait for the `STARTED` notification before cancelling. I think we can add a new latch that counts down in the worker’s `PropertyChangeListener` when `worker.getState() == SwingWorker.StateValue.STARTED` to mitigate this. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/31348#discussion_r3380622636
