Proposal Extending API for Streams (or other potentially long builder or chain calls)

[Constantine Plotnikov]

Hello All!

This email was previously filled as a feature request for JDK, I was
forwarded here to write it as an email.

Currently, if one needs to skip some stage or provide a group of reused
stages one to have to do the following:

Stream<T> s = collection.stream()
     .map(a -> doIt(a, bb))
    .filter(a -> !a.list().isEmpty());
s = useSecuriytFilter(s, session)
return s.collect(Collector.toList());

Or like:

return useSecuriytFilter(collection.stream()
     .map(a -> doIt(a, bb))
    .filter(a -> !a.list().isEmpty())
    , session);
    .collect(Collector.toList());

In both cases, readability is of code is not high, as fluent sequence of
actions is interrupted.

It is suggested to add "process" method to stream like the following
signature:

default <R> R process(Function<Stream<T>, R> body) {
   return body.apply(this);
}

Then custom processing could be applied like the following:

return collection.stream()
    .map(a -> doIt(a, bb))
    .filter(a -> !a.list().isEmpty()
    .process( s -> useSecuriytFilter(s, session))
    .collect(Collector.toList());

While semantics is the same, the code structure looks much better. Note
this proposed change is not about less typing, but about making local
processing looking more local, rather than affecting entire processing
pipeline visually.

The detailed description for motivation is here:

https://dzone.com/articles/making-java-fluent-api-more-flexible

Some other libraries with processing chain usage pattern like date-time
classes in java.util.time could benefit from this too as common blocks of
date arithmetic could be reused in more clean way.

A possibly better alternative to this functionality is the support for
extension methods like in Groovy, Kotlin, or C#, so users will be able to
create such methods when needed themselves, not waiting for library
designers. I think extension methods are good innovation enablers, as they
allow users of JDK or some library  to try new API ideas in the practice
first, and than to discuss their experience with component authors.

Best Regards,
Konstantin Plotnikov