API REVIEW: Weak event handler

[Lubomir Nerad]

Hi Sven,

in NetBeans they chose a different approach. Each weak event listener 
they create needs to hold a reference to the "source" on which it has 
been registered. First this requirement prevents it from being used with 
multiple sources and then it is prone to errors because the API allows 
to use different source during weak event handler creation and its 
registration. The nice thing is that their weak listeners handle 
everything internally and so their containers don't need to be aware 
about their existence.

If we wanted to use this approach for weak event handlers, we would 
require to provide and store more information for each event handler 
(source, eventType, isHandlerOrFilter) which would complicate weak event 
handler construction even further and increase possibilities for 
incorrect usage.

In my proposal I create only a simple weak event handler wrapper, which 
does very little work. It can be registered in the same way as any other 
event handler (even on multiple sources). But it requires its containers 
to be aware of its existence and handle it specially. Most use cases 
won't require do distinguish between EventHandler and WeakEventHandler, 
we need to have additional API for it only to provide possibility for 
adding (by external developers) new event handler containers (advanced 
use cases) which can handler weak event handlers correctly.

Thanks,
Lubo

On 6/12/2012 10:28 PM, Sven Reimers wrote:
> Ok. Here is a link to the JavaDoc how NetBeans handles this for PropertyChanges
>
> http://bits.netbeans.org/dev/javadoc/org-openide-util/org/openide/util/WeakListeners.html
>
> I still do not understand the necessity for creating a new interface,
> it contains no additional information (API) - for the user it can only
> be used as an EventListener (assuming there will be no API explicitly
> requiring WeakEventListener)..
>
> Regards
>
> Sven
>
> On Tue, Jun 12, 2012 at 10:01 PM, Richard Bair<richard.bair at oracle.com>  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 :-). What were the problems with WeakEventHandler being an interface?
>>
>> Thanks!
>> Richard
>
>