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