>> ReadAheadIterator - you know what I mean > No... The ReadAheadIterator would read one object ahead in a buffer.
>> ObjectStream ... > I\'m not sure of what you mean... The rationale goes like this: Iterators are not only views upon collections. An iterator/enumeration/object stream is (or at least faciliates) more of a \"programming paradigm\" (not really, but a design pattern). When you design for iterators, you design for handling streams of objects in a unified way, handling one object at a time. This means scalability and small memory footprint, important issues when it comes to server apps. Hence the need for iterators that can filter, that can decorate, that can merge with others etc, creating processing streams or pipelines. Or that can read ahead and take different actions depending on the next next object. java.util.Iterator is one Iterator. Here you ask if there is a next object first, and then tries to get it. But this means that the Iterator must know beforehand if the next object can be extracted, and this is not always the case. I therefore sometimes use a different interface: ObjectStream with the method: public Object next() throws Throwable; If the Object is null, the stream is empty. The implementation doesn\'t need to check if there is a next (which is sometimes impossible). Of course there are ObjectStreamIterator and IteratorObjectStream that adapts one to the other, but note that the ObjectStreamIterator needs a read ahead. The other method (borrowed from the io-streams) is public void close(). A very useful method, as this enables controlled clean-up where the client states that he is done with the stream. /O -------------------- [EMAIL PROTECTED] 0733 - 99 99 17 -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
