<Swing Dev> 7189299 DefaultButtonModel instance keeps stale listeners of JButton in case of multiple SwingUtilities.updateComponentTreeUI() calls

[Frank Ding]

Hi Pavel,
   Thanks for your comment pointing out the problems posed by static 
fields.  V4 cannot be an accepted work around unless static fields are 
avoided.  But I think in v4 removing stale listeners is only applied to 
those installed by FormView.
   I have revised the approach adopted in v4 where a JButtonWrapper 
class is declared for the purpose of accessing actionListener, 
changeListener and itemListener defined in its base class.  In addition, 
overriding setModel method in JButtonWrapper allows us to undo 
registration of aforementioned listeners on the newModel passed in as 
setModel method parameter.  In order to have FormView function correctly 
in terms of triggering the actionPerformed method defined in FormView,  
setModel also explicitly add FormView.this as action listener to the 
newModel.  Further more, setModel deregisters any action listeners of 
class FormView because that is the stale action listener registered by 
setModel last time.  In doing all the tricks in setModel, we 
successfully achieved the goal of removing stale listener while making 
FormView JButton properly function.

   By the way, I also updated the jtreg test case bug7189299.java a 
little bit to assert number of item listeners and change listeners 
because in setModel, the default changeListener and itemListener 
pertaining to the JButton are removed as well.

   The v5 code review is @
   http://cr.openjdk.java.net/~dingxmin/7189299/webrev.05/

   Your review is highly appreciated.

Thanks and best regards,
Frank

On 10/15/2012 5:16 PM, pavel porvatov wrote:
> Hi Frank,
>
> You are still removing all listeners, not only installed by FormView.
>
> You also introduced new static field (private static JButtonWrapper 
> currJButton = null), but there are a lot problems with static fields:
>
> 1. Memory leaks: static fields hold reference to potentially huge 
> objects unlimited time
> 2. Conflicts between applications from different AppContext (e. g. 
> applets)
> etc.
>
> So the best way is to avoid static fields at all.
>
> Regards, Pavel
>
> Hi Pavel,
>>   I happened to have another way of working around it though 
>> admittedly it's ugly.  Actually a good solution instead of a 
>> workaround requires either involving large code modification or 
>> introduction of new api.
>>   Idea of v4 change this time is keeping track of every 
>> JButtonWrapper instance once instantialized so that the listeners 
>> pertaining to stale JButton instance can be de-registered upon new 
>> JButton creation.
>>   You can check out code review below
>>   http://cr.openjdk.java.net/~dingxmin/7189299/webrev.04/
>>
>>   Your prompt comment is warmly welcomed and expected.
>>
>> Best regards,
>> Frank
>>
>>
>