Quite a few platforms make the specification of weak listeners explicit e.g.
in ActionScript you can specify a boolean in addEventListener that specifies
whether the event source should hold weak references to listeners. Therefore
I think whether you want an event source to hold a weak or strong reference
to your listener is really an application-level choice i.e. it is the
application logic's choice whether to supply an anonymous inner class
instance that will disappear unless the event source holds a strong
reference, or a named object that you want to be freed from memory when
*you* remove your references to it.

I think for many application programming problems, there is no nice way to
manage memory unless an event source offers to hold weak references to
listeners.

deregisterWatcher certainly works for things like locks where you do try {
lock.lock(); } finally { lock.unlock(); } but how about where you are
continually creating objects that maintain a copy of some items beneath
nodes (where, say, you are constantly changing your focus from one node to
another).

In this case, most probably you will want to create a primitive that
calls deregisterWatcher in finalize(). But the problem of course is that
finalize() will never get called.

For that reason, you end up with references to primitives on which you
*must* call close() before you lose a reference to them.

In practice, this is just not possible to do reliably which is why I don't
think there can be a substitute to weak references.

Best, Dominic

On 19 March 2010 18:47, Henry Robinson <he...@cloudera.com> wrote:

> (moved to zookeeper-dev)
>
> This API exposes internal implementation details which ties future versions
> of the client to supporting a particular set of semantics.
>
> I would prefer deregisterWatcher, as a result.
>
> Henry
>
> On 19 March 2010 03:11, Dominic Williams <thedwilli...@googlemail.com
> >wrote:
>
> > Hi I can see some people might be assigning for example anonymous class
> > instances as watchers/handlers, and not keeping any references to them.
> >
> > To avoid breaking existing use cases, two options:
> >
> > 1/ Add a useWeakReferences parameter to new constructor (sets default
> > behaviour)
> >
> > 2/ Add alternative methods, which take useWeakWatcherRef boolean.
> >
> > Internally will be trivial to have both
> >
> > private final Map<String, Set<Watcher>> dataWatches =
> >            new HashMap<String, Set<Watcher>>();
> >
> > private final Map<String, WeakSet<Watcher>> dataWatchesWeak =
> >             new HashMap<String, WeakSet<Watcher>>();
> >
> > On 18 March 2010 22:47, Ted Dunning <ted.dunn...@gmail.com> wrote:
> >
> > > This kind of sounds strange to me.
> > >
> > > My typical idiom is to create a watcher but not retain any references
> to
> > it
> > > outside the client.  It sounds to me like your change will cause my
> > > watchers
> > > to be collected and deactivated when GC happens.
> > >
> > > On Thu, Mar 18, 2010 at 3:32 AM, Dominic Williams <
> > > thedwilli...@googlemail.com> wrote:
> > >
> > > >
> > > > The current ZooKeeper client holds strong references to Watcher
> > objects.
> > > I
> > > > want to change the client so it only holds weak references. Feedback
> > > > please.
> > >
> >
>
>
>
> --
> Henry Robinson
> Software Engineer
> Cloudera
> 415-994-6679
>

Reply via email to