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

[Frank Ding]

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