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
