You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@commons.apache.org by Koji Sekiguchi <ko...@bluemartini.com> on 2004/08/18 02:11:45 UTC
[collections] WeakReference at CursorableLinkedList
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).
regards,
Koji
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org
RE: [collections] WeakReference at CursorableLinkedList
Posted by Koji Sekiguchi <ko...@bluemartini.com>.
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
Re: [collections] WeakReference at CursorableLinkedList
Posted by Simon Kitching <si...@ecnetwork.co.nz>.
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