On Mon, 17 Aug 2026 18:02:33 GMT, Kevin Rushforth <[email protected]> wrote:
>>> I don't see any harm in AWT sending such a message, although perhaps a CSR >>> is needed. >> >> Quite possibly this would need a CSR depending on how it is done. >> >>> The impact seems to be on the FX side, I don't know that I like that you >>> essentially force the JDK-baseline for FX to be one that has this fix. >> >> Yeah, I don't like this aspect of the fix at all. As it stands, it will >> queue up these messages indefinitely if you run an FX that has this fix with >> JDK 27. >> >>> Perhaps some other way to determine that AWT is loaded can be used. Or >>> there should be a "cap" on how long it waits. >> >> Or both. However it is implemented, I think we need to do the following: >> >> 1. A timeout and/or a max queue length so that it doesn't queue up an >> effectively unlimited number of these messages >> 2. Either implement a detection mechanism that doesn't require an AWT event >> (not sure whether it is feasible), or add a version check to disable this >> feature if the JDK version is < 28. This would be in addition to a system >> property or env var to disable it. >> >> Thinking out loud... another alternative would be for JavaFX to initialize >> AWT via a call to `Toolkit.getToolkit()` when we receive this event. That >> would mean the fix could be done entirely in JavaFX and you might not need >> to worry about queuing the messages, presuming the call could be done >> synchronously. This would need discussion and a CSR. > >>> Thinking out loud... another alternative would be for JavaFX to initialize >>> AWT via a call to `Toolkit.getToolkit()` when we receive this event. That >>> would mean the fix could be done entirely in JavaFX and you might not need >>> to worry about queuing the messages, presuming the call could be done >>> synchronously. This would need discussion and a CSR. > > ... > >> So I actually implemented Your feedback and the new implementation just >> requires a change on the JFX side. It uses a method invocation in the native >> part of the code to just call Toolkit.getDefaultToolkit() and therefore >> initializes AWT when receiving url events. > > I see that you did a proof of concept of my alternative thought. Presuming > that receiving the `NSApplicationDelegate application:openURLs:` event means > that it is reasonable for the AWT toolkit to be initialized, something like > this might work. I do like this better than the alternative of needing > coordinated changes on the AWT side. Have you tested it in various scenarios > to ensure that there are no problems initializing the toolkit from the AppKit > thread? You will also need to test what happens when the AWT Toolkit is > already initialized (although I can't think of any potential problems). > > As I mentioned above, this will need some discussion on the mailing list and > it will need a CSR, since it is a behavioral change. @kevinrushforth I've created a CSR based on that PR together with @pabulaner Here is the link: https://bugs.openjdk.org/browse/JDK-8391252 Any feedback on that - is there something we should change? ------------- PR Comment: https://git.openjdk.org/jfx/pull/2203#issuecomment-5436192378
