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

Remi Forax forax at
Mon Oct 29 17:31:42 UTC 2018

Jim Laskey ask for a similar feature on String, calling it "transform",
so i don't know if it's a good idea or not to add this API,
but at least the name should be the same.



----- Mail original -----
> De: "Constantine Plotnikov" <constantine.plotnikov at>
> À: "core-libs-dev" <core-libs-dev at>
> Envoyé: Vendredi 26 Octobre 2018 11:13:11
> Objet: Proposal Extending API for Streams (or other potentially long builder or chain calls)

> 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 =
>     .map(a -> doIt(a, bb))
>    .filter(a -> !a.list().isEmpty());
> s = useSecuriytFilter(s, session)
> return s.collect(Collector.toList());
> Or like:
> return useSecuriytFilter(
>     .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
>    .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:
> 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

More information about the core-libs-dev mailing list