Container.remove issue

[Alan Snyder]

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
>> 
>