API REVIEW: Weak event handler

[Lubomir Nerad]

Hi Richard,

On 6/12/2012 10:01 PM, Richard Bair wrote:
> Hi Lubo,
>
>> I also considered to define the WeakEventHandler as an interface which extends EventHandler, but adds no additional methods. Then leave it to event handler containers to reference such event handlers weakly. This has very simple and direct usage, but also its own problems. We can discuss it further if you find this solution preferred to the wrapper approach.
> Extending WeakReference and lacking the public constructor did make me a little weak in the knees :-).

Well, we can of course remove WeakReference from extends and have it as 
an instance in WeakEventHandler. But then we need to add some method to  
test whether the target handler has been garbage collected and will have 
one more instance for each created WeakEventHandler. So extending 
WeakReference seemed to me worth considering. On the other hand having 
additional test method is more consistent with Weak*Listener from 
javafx-beans so we will probably end up with it. As to the public 
constructor, I don't like having both (the factory method and 
constructor) and in this case the factory method seems to be easier to use.

> What were the problems with WeakEventHandler being an interface?
>

When somebody wants to register a single event handler weakly multiple 
times, in the case of WeakEventHandler as a wrapper (the first case), he 
needs only to create a single instance of it and register it multiple 
types. In the case of WeakEventHandler as a marker (the second case), 
each time he registers such event handler a new instance of weak 
reference needs to be created by the container for it. Also if such weak 
event handler is set to an event handler property (for example 
Node.setOnMousePressed), the property implementation needs to be ready 
for it and create a weak reference to it. Then when such event handler 
is finally garbage collected, the property needs to return null and 
ideally at the point of garbage collection it should notify its 
listeners (if any) about value change.

> Thanks!
> Richard

Lubo