Scala equivalent of java.util.stream

Question

Is there an Scala type (probably a trait) similar to java.util.stream.Stream ?

(I am using the better-supported Java 7, so Java 8's Stream is not available to me.)

Specifically, it must be generically typed, be iterable in some way, and be closeable.

try {
  stream.foreach(println)
  }
} finally {
  stream.close()
}

A solution in the standard libraries would be preferred, though something in another library would be acceptable.

Answer 1

For collections, all collections in Scala can be used as if they are streams. In Scala the operators on Iterable / Iterator are lazily applied for example and you also have Views and Stream ( Stream is a lazily evaluated List and does memoization of the traversed values, so if you want memoization you can use a stream, but because of the memory requirements this it tricky for working with infinite streams - still it's pretty cool).

As you might have noticed however, this doesn't take care of all cases, because the stream could be a stream of data coming from a network socket, file handle and so on. So one needs to dispose of the underlying resources used.

I do not know of a direct equivalent, however I must also mention that I do not like Java's streams, because Java's streams are for processing iterable sequences, which means that their current design is pull-based. This may change in the future, but when processing streams, especially streams involving I/O, it's better to go non-blocking and asynchronous, therefore I prefer push based approaches, like Iteratees , or the Reactive Extensions (Rx) pattern.

A lot is going on in the Scala/Java ecosystem in this regard. There is RxJava , which is an Rx.NET port. There's also Akka Streams , part of the Reactive Streams effort to specify an interoperable protocol for back-pressure - in the experimental/alpha stage.

And a shameless promotion - I'm working on Monifu , an Rx implementation for Scala, that does back-pressure and that will also be integrated with the "Reactive Streams" protocol. And I also think it's already in a better shape and more idiomatic than the RxScala adaptor of RxJava, but since I'm the author, take that with a grain of salt :-)