On Tue, 9 Jun 2026 13:35:19 GMT, Alexey Ivanov <[email protected]> wrote:
>> 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.
>
> Interesting…
>
> According to the comment in the test,
> https://github.com/openjdk/jdk/blob/b6fb712b6fcb1095c162ba15bf519045a8c451ae/test/jdk/javax/swing/SwingWorker/TestDoneBeforeDoInBackground.java#L94-L98
>
> by the time `doInBackground` starts the `START` notification will have been
> delivered. Thus `workerStarted.await` still covers this case.
What would be the behaviour if `cancel` is called before `doInBackground`
starts? Should we create a test for it, if at all possible?
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/31348#discussion_r3381032219
