[Biojava-dev] AnnotationForwarder

Schreiber, Mark mark.schreiber@agresearch.co.nz
Fri, 1 Nov 2002 14:23:08 +1300


OK so no need to 'fix' the BioSQL stuff then.

I'm going to make all references to the AnnotationForwarder transient so
that listeners don't get dragged into serialization.

- Mark


> -----Original Message-----
> From: Thomas Down [mailto:td2@sanger.ac.uk] 
> Sent: Friday, 1 November 2002 2:18 p.m.
> To: biojava-dev@biojava.org
> Subject: Re: [Biojava-dev] AnnotationForwarder
> 
> 
> On Fri, Nov 01, 2002 at 01:59:12PM +1300, Schreiber, Mark wrote:
> > Would it be a good idea to add a method to Annotatable called
> > getAnnotationForwarder() as a reminder that the AnnotationForwarder 
> > needs to be implemented?
> > 
> > Obviously this would break lots of stuff so might not be a very 
> > attractive solution.
> 
> Please no.
> 
> The AbstractChangable/ChangeSupport/ChangeForwarder 
> mechanisms are a reasonable stab at providing a `general 
> purpose' implementation of the ChangeEvent framework, 
> especially since Matthew refactored them and thrashed them 
> about a bit.  However, if you've got events being forwarder 
> around a fairly complex graph of objects, the number of 
> ChangeSupport and ChangeListener objects can 
> rapidly become large.  Their existence also means that any 
> object which has listeners is effectively `locked' into 
> memory.  This just doesn't worth for big databases.  I've 
> implemented a number of systems which ignore these default 
> implementations.  The most obvious is the latest incarnation 
> of the biojava-biosql.  This has a ChangeHub object which 
> fakes all the event forwarding behind the scenes, even if an 
> event is actually being forwarded through an object which 
> isn't currently loaded in memory.
> 
> While I welcome any attempt to identify and fix classes which 
> are genuinely missing necessary event-handling logic (and I 
> know there are a number of these), it should still be 
> possible to write objects which use non-standard event 
> implementations (or, for that matter, no implementation at 
> all in cases where this underlying data isn't going to change).
> 
>      Thomas.
> _______________________________________________
> biojava-dev mailing list
> biojava-dev@biojava.org 
> http://biojava.org/mailman/listinfo/biojava-dev
> 
=======================================================================
Attention: The information contained in this message and/or attachments
from AgResearch Limited is intended only for the persons or entities
to which it is addressed and may contain confidential and/or privileged
material. Any review, retransmission, dissemination or other use of, or
taking of any action in reliance upon, this information by persons or
entities other than the intended recipients is prohibited by AgResearch
Limited. If you have received this message in error, please notify the
sender immediately.
=======================================================================