Advantages of Stream and Spring Data

Question

Some people override the CrudRepository\'s method findAll to return an Stream (java 8), but I saw they finally transform the Stream to a List in order to send it through a rest

Answer 1

Providing it as a Stream gives the repository consumer the choice on how to collect the data. In addition it allows chaining/piping of operations on the stream, such as mapping to DTOs, augmenting data, and filtering. If the only thing you're ever going to do is collect it to a list and send as a response, then there is no benefit.

But take for example the case where a Thing repository returns a List<Thing> findAllThings() of n Thingss because most of the time it's just sent as a list via the API. But then someone builds a service in the application that needs to filter only Things that exist in another set of m Things in the application. We would have to recreate a list filtering on the set like

List<Thing> acceptedThings = repo.findAllThings()
                                 .stream()
                                 .map(t->set.contains(t))
                                 .collect(toList());

So we've had to iterate the original list and reconstruct a new list. If there are further operations on this list, you can see how it may be sub-optimal.

If the response from the repository had been Stream<Thing> then we could have chained the filter operation and passed on the Stream for any further processing.

Stream<Thing> acceptedThings = repo.findAllThings()
                                   .map(t->set.contains(t));

Only right at the end when something consumes the stream will execute all the operations relevant for each item. This is much more efficient as each element only needs to be visited at most once and no intermediate collections need to be created.

Given that Spring now supports returning Streams as @ResponseBody's in controllers, it's even better.

Answer 2

There might be various reasons why people want to use Streams.

1. If you do any processing that you can't or don't want to do in the database, Streams might be nicer to work with.

2. It's so hip and "functional". Almost everybody still seems to be experimenting what the right combination of features is. So it is perfectly possible and even likely that there is no benefit in using Streams. But then, it doesn't cost much either.

Answer 3

This is already supported in Spring Data JPA, look here; so there's not real advantage to override those to return Stream. If you really want a Stream and some potential advantages that would come with it - use what already Spring Data JPA provides.

And also a different aspect is that in JPA Spec 2.2 this could be the default return type of some queries. The JPA interfaces Query and TypedQuery will get a new method called getResultStream().

So Spring Data will use techniques specific to a particular provider, like Hibernate or EclipseLink to stream the result.

By default getResultStream is just a list.stream implementation, but Hibernate already overrides that with ScrollableResult. This is way more efficient if you need to process a very big result set.