On Wed, 27 May 2026 17:26:21 GMT, Sergey Bylokhov <[email protected]> wrote:
>>> AFAICS, we can get into a situation where a posted event is silently
>>> ignored if the event EQ has not been initialized by that point.
>>
>> So we need to make sure it is. And there are two ways to do it. I've opted
>> for one of them.
>>
>>> Previously, we always had AppContext initialized when `postEvent()` was
>>> called, correct me if I am wrong.
>>
>> Not by design as far as I can tell. If it was true it was by accident.
>>
>>
>>>
>>> > In postEvent() itself was the only other option that worked but then it
>>> > is checked every time an event is posted.
>>>
>>> We can make the check relatively cheap in `postEvent()`, for example:
>>>
>>> ```java
>>> PostEventQueue eq = postEventQueue; // volatile read
>>> if (eq == null) {
>>> initEQ(); // call synchronized method only when necessary
>>> eq = postEventQueue;
>>> }
>>> eq.postEvent(event);
>>
>> Yes, I know and that is the pattern I would use if we went that route.
>>
>>> ```
>>>
>>> Regardless of whether we implement this change in `postEvent()`, we can
>>> apply the same optimization in `getSystemEventQueueImplPP()` to avoid
>>> calling a synchronized method every time:
>>
>> That's true, and I thought about it but it didn't seem a big deal because
>> that's infrequent and no different than today
>>>
>>> ```java
>>> public static EventQueue getSystemEventQueueImplPP() {
>>> EventQueue eq = currentEventQueue;
>>> if (eq == null) {
>>> initEQ();
>>> eq = currentEventQueue;
>>> }
>>> return eq;
>>> }
>>> ```
>
> If we want to always init in the constructor, then we can drop initialization
> in `getSystemEventQueueImplPP` and make it unconditional?
>
> It is also unclear how it is interact with `EventQueue.push` which may change
> `SunToolkit.currentEventQueue` but not `SunToolkit.postEventQueue`, I cannot
> find a way to init it out of order, but maybe it is possible?
getSystemEventQueueImplPP() is a static method.
So it may be called before the Toolkit is initialized.
And I don't see the need to do this. No harm can come of leaving it, but no
obvious good - and probable harm - will come from removing it.
I have no reason to suppose any ordering problem here.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/31262#discussion_r3312690957
