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:[EMAIL PROTECTED] > 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: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
