commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ola Berg <>
Subject [Collections] Iterators and ObjectStreams
Date Thu, 13 Jun 2002 08:53:28 GMT
>> 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.


0733 - 99 99 17

To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message