commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Koji Sekiguchi" <koji.sekigu...@bluemartini.com>
Subject RE: [collections] WeakReference at CursorableLinkedList
Date Wed, 18 Aug 2004 03:52:25 GMT
Hi Simon,

Thank you for your kind reply.
I've looked at CursorableLinkedList and Cursor close() source code
and read javadoc, I was confused. Why the class uses WeakReference
because if it doesn't WR, when application releases cursor reference
but the class doesn't release the cursor reference, so it should
use WR to hold cursor references in order to avoid memory leak, right?
Now I think I understand about "backwards compatibility" and
"CursorableLinkedList implementation with WR".

Thank you again,

Koji

> -----Original Message-----
> From: Simon Kitching [mailto:simon@ecnetwork.co.nz]
> Sent: Wednesday, August 18, 2004 11:52 AM
> To: Jakarta Commons Users List
> Subject: Re: [collections] WeakReference at CursorableLinkedList
> 
> 
> On Wed, 2004-08-18 at 12:11, Koji Sekiguchi wrote:
> > In CursorableLinkedList class javadoc, it says
> > 
> > "Closing the cursor is optional because references are held via a
> > WeakReference."
> > 
> > I cannot understand what advantage is by having WeakReference to hold
> > cursor references from applications perspective? Although the javadoc
> > says about backwards compatibility and application may be able to close
> > the cursor, I think the class can just provide NOP close method for
> > backwards
> > compatibility (without WeakReference).
> 
> Hi Koji,
> 
> The issue is that:
> 
> (a) CursorableLinkedList implements the standard List interface. It
> should be possible for code to access an instance of List without caring
> whether it is a "normal" LinkedList or a CursorableLinkedList. But
> without the weak reference implementation, there is a significant
> difference: when the List object is actually a CursorableLinkedList, the
> object returned by the listIterator() function must be cast to Cursor
> then closed to avoid memory leaks. This essentially makes it impossible
> to replace a List object with a CursorableLinkedList object.
> 
> (b) Cursor implements ListIterator. But if you pass it off to a method
> that expects a normal ListIterator, that method will not call close() on
> it at end, and so a memory leak will occur.
> 
> The comment about backwards compatibility is simply to point out why
> there is a getCursor() method at all, when the listIterator() method
> also returns a Cursor object, and is defined in the standard List API.
> There really isn't any need for a getCursor() method at all now, but in
> earlier implementations without the WeakReference implementation you
> *did* have to explicitly close the cursor to avoid memory leaks - and
> therefore had major problems with situations like (a) and (b) above. So
> it was easier to use a getCursor method that returned the real type than
> a listIterator method where you always had to cast the result.
> 
> Regards,
> 
> Simon
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-user-help@jakarta.apache.org
> 
> 

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org


Mime
View raw message