RFR: 8371128: NullPointerException occurs due to double cleanup of SwingNode [v2]
Prasanta Sadhukhan
psadhukhan at openjdk.org
Wed Nov 5 03:04:18 UTC 2025
On Tue, 4 Nov 2025 17:58:09 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:
>> BUT, in line 555 we are accessing lwFrame from the FX app thread, in a completely unsafe manner - test followed by use.
>
> Good catch. Other than being another possible source of an NPE, that one seems unrelated, so might be better handled as a follow-up. This one isn't a threading issue whereas the one you pointed out is.
>
> @prsadhuk Can you at least take a look at it and see whether there is any relation to the bug you are fixing? If not, let's file a follow-up bug. The fix is to also check for null on the EDT before calling createUngrabEvent (as is done in disposeLwFrame -- even if you test lwFrame for null in the FX thread (to short-circuit creating the call on the EDT), you still need to check before use once you actually are on the EDT.
I don't quite understand..In
private final EventHandler<FocusUngrabEvent> ungrabHandler = event -> {
556 if (!skipBackwardUnrgabNotification) {
557 if (lwFrame != null) {
558 postAWTEvent(
559 swNodeIOP.createUngrabEvent(lwFrame));
560 }
561 }
562 };
we are checking for null lwFrame in FX thread and there's no thread switching so how can we have again null lwFrame?
In disposeLwFrame, we are checking for null lwFrame inside `SwingNodeHelper.runOnEDT` due to context switch but here no such thing is happening and is running in same thread, so I am not sure why and where to `check for null on the EDT before calling createUngrabEvent`
-------------
PR Review Comment: https://git.openjdk.org/jfx/pull/1960#discussion_r2492695377
More information about the openjfx-dev
mailing list