It looks like the synchronized block is designed to prevent concurrent modification of the list. I don't believe that particular code would suffer the consequences if concurrent modification occurred, but it's generally best to synchronize list access when in doubt, since even a simple iteration can be the offender.
-----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Øyvind Harboe Sent: Friday, June 20, 2008 9:46 AM To: [EMAIL PROTECTED] Subject: weakly referenced paged queries I'm toying around with weak references in paged queries. This turned out to be rather hairy from the point of view that a query is supposed to return a List and this List has to live up to a lot of expectations from the calling code + promises of the List interfaces. Consider two of the subList implementations in IncrementalFaultList: a) public List<E> subList(int fromIndex, int toIndex) { synchronized (elements) { resolveInterval(fromIndex, toIndex); return elements.subList(fromIndex, toIndex); } } b) public List<E> subList(int fromIndex, int toIndex) { List<E> l=new LinkedList<E>(); for (int i=fromIndex; i<toIndex; i++) { l.add(get(i)); } return l; } 1. JavaDoc states that list.subList(from, to).clear() will clear that range. Here b) is broken. 2. I was greatly surprised to see synchronized() for the list returned from the query. Is the synchronisation for the benefit of the calling code or the implementation? Attached is the work in progress. First and foremost I'm after measuring the performance of such an implementation. So far it doesn't look very promising. It does use less memory but it is dog slow. Will tinker with it more. -- Øyvind Harboe http://www.zylin.com/zy1000.html ARM7 ARM9 XScale Cortex JTAG debugger and flash programmer
