Hi Ludger,
"Ludger Buenger" <[EMAIL PROTECTED]> wrote on 03/08/2007
05:47:34 AM:
> Hi Michael, thanks for your quick answer.
>
> Ok, Here I send a first proposal for changes as a patch regarding
> Ranges and weak references.
> It should not be difficult to apply similar changes to NodeIterators.
Thanks for the contribution. Could you please create a new JIRA issue [1]
and attach your patch to it?
I also need to ask you to fax an Individual Contributor License Agreement
(CLA) [2] to Apache since I couldn't find one on file [3] for you.
According to the Xerces project charter [4] in order to accept new
features and other enhancements into the project the developer
contributing the code must have a CLA on file with Apache. Signing a CLA
will cover your improvements for Ranges as well as future contributions to
Xerces (and other Apache projects).
> A more optimized implementation would likely make use of reference
> queues removing the need to actively check the weak reference's
> content upon each range update by DocumentImpl.
>
> Since I am not proficient regarding java.io.Serialization at all
> someone more competent in this matter has to check whether something
> like this would break serializability.
I can take care of that. I suspect the ranges field should be made
transient. Not sure why it wasn't declared transient in the first place.
> Internally we were also thinking about EventListeners to use
> WeakReferences however I think that references to objects provided
> by an external application should not be weak (which I think applies
> to EventListener and user data).
>
> However classes xerces provides to the application where xerces
> stores an reference in order to be able to update it's content can
> be weak and thus garbage collectable (which I think applies to
> Ranges and NodeIterators).
>
>
> The following is a use case where a weak reference to an
> EventListener could cause undesired behaviour.
>
> Imagine an EventListener implementation that solely logs all events
> to System.out or a file:
>
> node.addEventListener(MutationEventImpl.DOM_SUBTREE_MODIFIED,
> new EventListener() {
> public void handleEvent( Event evt ) {
> System.out.println( "Subtree Modification Event
> occured" );
> }
> }, true );
>
>
> The only reference to this EventListener resides inside the DOM
> implementation.
> If I am not mistaken usage of WeakReferences inside the DOM
> implementation here would result in the logging EventListener
> eventually being garbage-collected and thus cease event logging, right?
Yes, but that's not what I was thinking of. It's not the EventListener or
the user data which needs the WeakReference. It's the node that they're
associated with that needs it.
In order to save memory per node instance we decided to store
EventListeners and user data on the Document node in Hashtables. When you
register an EventListener or set user data it's inserted into one of these
Hashtables along with the associated node (which is the key). If you later
remove the node from its parent in the DOM and drop all your references to
it, it and the EventListener/user data can't be garbage collected because
the Document still has references to them. To get the node to be GC'd you
would also have to remove the EventListener or user data from the node.
Certainly less intuitive than Range.detach() and only necessary because of
an implementation decision we made. Applications shouldn't be expected to
do that.
> Same applies to user data: It might happen, that an application
> provides user data and relies upon the node implementation to hold
> on to it until the application retrieves the user data from the node
again.
>
>
> Thanks,
>
> Ludger Bünger
> --
> Dipl.Inf. Ludger Bünger
> RealObjects GmbH
[1] http://issues.apache.org/jira/browse/XERCESJ
[2] http://www.apache.org/licenses/icla.txt
[3] http://people.apache.org/~jim/committers.html
[4] http://xml.apache.org/xerces2-j/charter.html
Michael Glavassevich
XML Parser Development
IBM Toronto Lab
E-mail: [EMAIL PROTECTED]
E-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
