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

[Ivan Gerasimov]

Hello Constantine!

It seems that a request for such method was made in JDK-8210372 
<https://bugs.openjdk.java.net/browse/JDK-8210372>.
I like the method name chain(), proposed in that request.

With kind regards,
Ivan


On 10/26/18 2:13 AM, Constantine Plotnikov wrote:
> 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
>

-- 
With kind regards,
Ivan Gerasimov