Container.remove issue

[Andy Goryachev]

As a fellow Swing developer, let me suggest that one should avoid changing the component hierarchy in the middle of another change.  EventQueue.invokeLater() might be a solution to this problem.

Cheers,
-andy



From: client-libs-dev <client-libs-dev-retn at openjdk.org> on behalf of Alan Snyder <javalists at cbfiddle.com>
Date: Wednesday, November 8, 2023 at 11:59
To: Philip Race <philip.race at oracle.com>
Cc: client-libs-dev at openjdk.org <client-libs-dev at openjdk.org>
Subject: Re: Container.remove issue
I stand corrected.

It is Component.removeNotify (called on a text field that is the focus owner) that clears the global
focus owner, triggering a focus changed event.

My point is that my application code is not violating the advice about removeNotify, but
the problem still occurs because my focus event listener is “doing something”.

Hence my question, is there (or should there be) advice about event listeners not
“doing something”?

I still see no reason for Container.remove not to employ defensive programming.
Maybe 20 years ago the performance cost of an extra array reference was considered
a problem, but I can’t see it being a problem today.

  Alan



> On Nov 8, 2023, at 10:49 AM, Philip Race <philip.race at oracle.com> wrote:
>
> The AppContext.remove() call just removes an entry from a map and doesn't affect the UI.
> And anyway the caution is about application code doing something.
>
> -phil.
>
> On 11/7/23 3:31 PM, Alan Snyder wrote:
>>> On Nov 7, 2023, at 2:57 PM, Philip Race <philip.race at oracle.com> wrote:
>>>
>>> I don't have a definite answer to your question, and for sure AWT docs may be a bit lacking,
>>> but there's also a lot of them so an answer may be buried somewhere.
>>>
>>> Not sure if you are saying you are in fact running "arbitrary code" in removeNotify() but
>>> I don't think that would be a good idea. You can observe in there but I'm not sure
>>> you should "do" anything. Also per the docs you need to call the superclass method as the first line.
>>>
>>> There's this old bug report https://bugs.openjdk.org/browse/JDK-4074274 which might be useful to read.
>>>
>>> -phil.
>>>
>>
>> Interesting, but In this case, it is JTextComponent that is “doing something”.
>>
>>    public void removeNotify() {
>>         super.removeNotify();
>>         if (getFocusedComponent() == this) {
>>             AppContext.getAppContext().remove(FOCUSED_COMPONENT);
>>         }
>>     }
>>
>> Is there similar advice not to “do something” in a focus event listener?
>>
>> I’m not seeing an argument against using some “defensive programming” in Container.remove.
>>
>> It would be odd if some application depended upon removing a different component.
>>
>>   Alan
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/client-libs-dev/attachments/20231108/535f9d16/attachment.htm>