7189299 DefaultButtonModel instance keeps stale listeners of JButton in case of multiple SwingUtilities.updateComponentTreeUI() calls (original) (raw)
Frank Ding dingxmin at linux.vnet.ibm.com
Mon Sep 17 06:34:03 UTC 2012
- Previous message: 7189299 DefaultButtonModel instance keeps stale listeners of JButton in case of multiple SwingUtilities.updateComponentTreeUI() calls
- Next message: Review Request - Jcolorchooser Missing accessible name
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Hi Pavel, Thanks for your comment. I improved my fix again and uploaded to the following address http://cr.openjdk.java.net/~dingxmin/7189299/webrev.03/
This revision offers a different approach where
- In ComponentView, setComponentParent method, the best place that is entitled to detect de-registration condition because only in class ComponentView can var "Invalidator c" be accessed.
- If the condition is satisfied (this.getParent()==null && c.getParent() !=null), call a newly added protected method "cleanup" to let subclass do house clean up work.
- FormView.cleanup does the actual work of removing listeners from DefaultButtonModel.
- However, listener instances to be de-registered are protected members of AbstractButton, we need to have a JButton wrapper exposing these listeners, which leads to declaration of JButtonWrapper inner class.
I think this time is much better than the reflection one. Could you please take a took and give your comment? I may need to refine javadoc of cleanup protected method later.
Thanks and best regards, Frank
On 9/13/2012 7:50 PM, Pavel Porvatov wrote:
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
- Previous message: 7189299 DefaultButtonModel instance keeps stale listeners of JButton in case of multiple SwingUtilities.updateComponentTreeUI() calls
- Next message: Review Request - Jcolorchooser Missing accessible name
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]