The stream abstraction and substream()

[Jose]

When comparing the present Stream<T> abstraction with other similar
abstractions I'm using in my code, 
mainly byte streams for reading/writing binary files, I miss the most common
operations I use: doing limited reads of the stream. 
For example a can read a byte, a short, a byte array with the following n
elements and so on.

For Stream<T> and restricting to n=1 to keep it simple, the equivalent
operation would be: 
                   
                     T  next()  

But for Streams supporting concatenation, a very clever design, the reading
operations has to return a Stream, so in the pipeline context 
the operation should be in fact:

                Stream<T> next(Consumer<T> c)


Reading the Stream documentation I see that Stream<T> supports a kind of
"skip" operation:


                      Stream<T> substream(long startingOffset)


Which is described as  "producing a Stream consistent of the elements of
this stream, discarding the first startingOffset elements" 
If you are not going to read these elements, I would prefer the name skip(n)
more than substream(n), because substream says little in the pipeline
context, 
almost everything produces a stream, and a filter can also be seen as
producing a kind of substream.

The problem with this operation is that it really skips n elemets doing
nothing with them. As you can't process them, you can't emulate a next()
operation for example.

So my question is, why not implement a more general operation instead (maybe
using other name)

                      Stream<T> substream(long n, Consumer<T>)

and give the user the chance of processing the first n elements of the
stream?. 

Or I missing someting important here? 


Regards