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

Frank Ding dingxmin at linux.vnet.ibm.com
Thu Sep 13 02:44:31 UTC 2012


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

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




More information about the swing-dev mailing list