<html xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
        {font-family:"Cambria Math";
        panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
        {font-family:Calibri;
        panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
        {font-family:"Iosevka Fixed SS16";
        panose-1:2 0 5 9 3 0 0 0 0 4;}
@font-face
        {font-family:"Times New Roman \(Body CS\)";
        panose-1:2 11 6 4 2 2 2 2 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
        {margin:0in;
        font-size:10.0pt;
        font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
        {mso-style-priority:99;
        color:blue;
        text-decoration:underline;}
span.EmailStyle19
        {mso-style-type:personal-reply;
        font-family:"Iosevka Fixed SS16";
        color:windowtext;}
.MsoChpDefault
        {mso-style-type:export-only;
        font-size:10.0pt;
        mso-ligatures:none;}
@page WordSection1
        {size:8.5in 11.0in;
        margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
        {page:WordSection1;}
--></style>
</head>
<body lang="EN-US" link="blue" vlink="purple" style="word-wrap:break-word">
<div class="WordSection1">
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Iosevka Fixed SS16"">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.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Iosevka Fixed SS16""><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Iosevka Fixed SS16"">Cheers,<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Iosevka Fixed SS16"">-andy<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Iosevka Fixed SS16""><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Iosevka Fixed SS16""><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Iosevka Fixed SS16""><o:p> </o:p></span></p>
<div id="mail-editor-reference-message-container">
<div>
<div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal" style="margin-bottom:12.0pt"><b><span style="font-size:12.0pt;color:black">From:
</span></b><span style="font-size:12.0pt;color:black">client-libs-dev <client-libs-dev-retn@openjdk.org> on behalf of Alan Snyder <javalists@cbfiddle.com><br>
<b>Date: </b>Wednesday, November 8, 2023 at 11:59<br>
<b>To: </b>Philip Race <philip.race@oracle.com><br>
<b>Cc: </b>client-libs-dev@openjdk.org <client-libs-dev@openjdk.org><br>
<b>Subject: </b>Re: Container.remove issue<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="margin-bottom:12.0pt"><span style="font-size:11.0pt">I stand corrected.<br>
<br>
It is Component.removeNotify (called on a text field that is the focus owner) that clears the global<br>
focus owner, triggering a focus changed event.<br>
<br>
My point is that my application code is not violating the advice about removeNotify, but<br>
the problem still occurs because my focus event listener is “doing something”.<br>
<br>
Hence my question, is there (or should there be) advice about event listeners not<br>
“doing something”?<br>
<br>
I still see no reason for Container.remove not to employ defensive programming.<br>
Maybe 20 years ago the performance cost of an extra array reference was considered<br>
a problem, but I can’t see it being a problem today.<br>
<br>
  Alan<br>
<br>
<br>
<br>
> On Nov 8, 2023, at 10:49 AM, Philip Race <philip.race@oracle.com> wrote:<br>
> <br>
> The AppContext.remove() call just removes an entry from a map and doesn't affect the UI.<br>
> And anyway the caution is about application code doing something.<br>
> <br>
> -phil.<br>
> <br>
> On 11/7/23 3:31 PM, Alan Snyder wrote:<br>
>>> On Nov 7, 2023, at 2:57 PM, Philip Race <philip.race@oracle.com> wrote:<br>
>>> <br>
>>> I don't have a definite answer to your question, and for sure AWT docs may be a bit lacking,<br>
>>> but there's also a lot of them so an answer may be buried somewhere.<br>
>>> <br>
>>> Not sure if you are saying you are in fact running "arbitrary code" in removeNotify() but<br>
>>> I don't think that would be a good idea. You can observe in there but I'm not sure<br>
>>> you should "do" anything. Also per the docs you need to call the superclass method as the first line.<br>
>>> <br>
>>> There's this old bug report <a href="https://bugs.openjdk.org/browse/JDK-4074274">
https://bugs.openjdk.org/browse/JDK-4074274</a> which might be useful to read.<br>
>>> <br>
>>> -phil.<br>
>>> <br>
>> <br>
>> Interesting, but In this case, it is JTextComponent that is “doing something”.<br>
>> <br>
>>    public void removeNotify() {<br>
>>         super.removeNotify();<br>
>>         if (getFocusedComponent() == this) {<br>
>>             AppContext.getAppContext().remove(FOCUSED_COMPONENT);<br>
>>         }<br>
>>     }<br>
>> <br>
>> Is there similar advice not to “do something” in a focus event listener?<br>
>> <br>
>> I’m not seeing an argument against using some “defensive programming” in Container.remove.<br>
>> <br>
>> It would be odd if some application depended upon removing a different component.<br>
>> <br>
>>   Alan<br>
>> <br>
> <o:p></o:p></span></p>
</div>
</div>
</div>
</div>
</body>
</html>