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

[Pavel Porvatov]

Hi Frank,
> Hi Pavel
>   It's been a long time since last discussion.  Now I have a new 
> approach to the issue.
>   The basic idea is removing the listener pertaining to JButton 
> instance from DefaultButtonModel when the corresponding FormView 
> instance is about to retire.
>
>   The best place I can find in source code to achieve it is in 
> FormView's super class ComponentView, method void setComponentParent.
>   View p = getParent();
>   if (p != null) {
>      ....
>   } else {
>     // when p is null, it means the FormView instance is about to retire
>     // deregister listener off shared DefaultButtonModel instance
>   }
>
>   However, the biggest problem is that the listener to be removed is a 
> private member of AbstractButton and the only way is holding the 
> listener object and then calling various removeXXXListener on 
> DefaultButtonModel with the listener being parameter.  I have to 
> resort to reflection which makes it look more like a workaround. 
> What's more, reflection introduces implementation dependency.
>   In addition to the change to fix, I also updated its jtreg test case 
> according to your comments.
>   Could you please review it again @
> http://cr.openjdk.java.net/~dingxmin/7189299/webrev.02
We don't use reflection in the SWING library. Could you please try to 
find another way of fix?

Regards, Pavel

>
>   Thanks,
>   Frank
>
>
> On 8/16/2012 12:19 AM, Pavel Porvatov wrote:
>> 1. Could you name the test from lower case? There is no strict rules 
>> for that, but most tests starts from "bug..."
>> 2. You should use the SunToolkit.realSync method to be sure that 
>> frame became visible. Take a look in other test, e.g. 
>> test/javax/swing/JPopupMenu/7156657
>> 3. You can reduce code and put try/finally block into single 
>> SwingUtilities.invokeAndWait
>> 4. About the fix: you are removing ALL listeners from public model. 
>> That can lead to regressions and this behavior is not expected from 
>> users.
>>> The regression mark was a mistake.  If possible, could you clear 
>>> regression status?
>> Ok, I removed the regression keyword
>>>
>>> http://cr.openjdk.java.net/~dingxmin/7189299/webrev.01/
>>>
>>>   Please review the new one.  Thanks
>>>
>>> Best regards,
>>> Frank
>>>
>>
>