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

[pavel porvatov]

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
>
>
> On 10/10/2012 2:22 PM, Frank Ding wrote:
>> Hi Pavel,
>>   Thanks for your comment yet.  I will think about it in other way, 
>> perhaps other way to work around it without api change.
>>
>> Best regards,
>> Frank
>>
>> On 10/9/2012 11:20 PM, pavel porvatov wrote:
>>> Hi Frank,
>>>> Hi Pavel,
>>>>   Thanks for you reply.  I have thought it through and have to have 
>>>> this solution.  The pain point is that these private access level 
>>>> listeners are completely encapsulated.  But there is another 
>>>> possible fix that won't bother introducing cleanup api but would 
>>>> require
>>>> 1.  Make ComponentView.setComponentParent method become protected 
>>>> for FormView to override (package level is not adequate because 
>>>> FormView resides under a different package). This allows FormView 
>>>> instance to determine de-registration condition.
>>> That's public API changing
>>>
>>>> 2.  Make ComponentView.c (private Invalidator c) become protected 
>>>> for FormView to access.
>>> That's public API changing as well
>>>>
>>>>  It doesn't bring about new cleanup public api but make hidden 
>>>> setComponentParent and c come to surface.  Do you think it is 
>>>> preferable than cleanup one? 
>>> I believe we should try to find a fix without API changes
>>>
>>>> Or I would be more than glad to know another approach.
>>> Unfortunately I don't have time to fix this problem. Does somebody 
>>> else have ideas about the fix?
>>>
>>> Regards, Pavel
>>>
>>
>