RFR: JDK-8318854: [macos14] Running any AWT app prints Secure coding warning [v2]
Phil Race
prr at openjdk.org
Fri Nov 10 22:41:57 UTC 2023
On Fri, 10 Nov 2023 22:31:34 GMT, Phil Race <prr at openjdk.org> wrote:
>> To access any native code in AWT the app should initially init the LWCToolkit which sets that application delegate if it is not set already. Do we know how the FX can bypass that initialization?
>
> In the case when AWT is embedded AWT does NOT start an NSApplication and does not own it.
> AWT overwriting FX's delegate, or any one else's is just plain wrong.
>
> We can turn around what you said
> "To access any native code in JavafX, the app should initialise GlassToolkit which sets its delegate, if not already set".
>
> But you can't have both of these.
>
> Meaning AWT isn't special here. It has to play by the same rules.
>
> The toolkit that starts the NSApplication is the one that should be setting the delegate.
> If you are embedded in someone else's application, it seems most logical that you defer to their application
> and if this means some things aren't possible, so be it.
> Can you please provide details on how the delegate can be null here and there if it should be set at the startup of any awt application?
I commented on these in https://bugs.openjdk.org/browse/JDK-8319255 which is now closed as a dup.
There I wrote (in part)
#######
I am not sure if these are all cases that can provably be in un-reachable code in the "nil" case, which
means some embedded case. But if we ever do reach them, it seems we'd crash the app.
And if we need to make the delegate "nil" in the non-subclassed NSApplication case (ie like FX)
then we are more likely to cause a crash.
[list of places elided]
All these call sites need to be examined to understand that, and if necessary a test developed to
confirm it.
And even then, it might be prudent to add checks for nil.
#####
So the request was to investigate and understand if they were needed, not just add them
@honkar-jdk can comment on what she did there.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/16569#discussion_r1389988271
More information about the client-libs-dev
mailing list