RFR 8144675: Add a filtering collector

ShinyaYoshida bitterfoxc at gmail.com
Tue Dec 8 09:59:37 UTC 2015


Hi Paul,
Thank you for your review.
(Especially, about doc comment, it's very helpful for non-native speaker
like me ;) )

2015-12-08 18:27 GMT+09:00 Paul Sandoz <paul.sandoz at oracle.com>:

> Hi,
>
> Looks good.
>
> Just minor comments.
>
> Would you mind limiting the text (not the example code) in the JavaDoc to
> the 80 limit?


Oops, I've not minded, I'll be careful.

I update my webrev to take your suggestions:
http://cr.openjdk.java.net/~shinyafox/8144675/webrev.02/

Regards,
shinyafox(Shinya Yoshida)


> Collectors
>>
>  455      * Adapts a {@code Collector} accepting elements of type {@code
> T} which is filtered by filtering predicate to
>  456      * each input element before accumulation.
>
> Suggest the following:
>
>   Adapts a {@code Collector} to one accepting elements of the same type
> {@code T}
>   by applying the predicate to each input element and only accumulating if
>   the predicate returns {@code true}
>
>
>  462      * {@code Employee}, to accumulate the number of employee which
> is filtered the salaly in each department:
>
> Suggest the following:
>
>   , to accumulate the number of employees in each department
>   that have a salary above a certain threshold:
>
> Actually based on your latest email it might be clearer to replace
> counting() with toList()/toSet() to avoid the ambiguity with toMap and
> summation:
>
>   For example, given a stream of {@code Employee}, to accumulate the
> employees in
>   each department that have a salary above a certain threshold:
>
>  Map<Department, Set<Employee>> wellPaidEmployeesByDeparetment
>   = employees.stream().collect(groupingBy(Employee::getDepartment,
>                                                  filtering(e ->
> e.getSalary() > 2000, toset())));
>
>
> (Since we don’t specify the monetary units, it is left as an exercise to
> speculate whether this is well paid or not :-) ).
>
>
>  472      * @param filter a predicate to be applied to the input elements
>
> s/filter/predicate (and likewise for the method argument).
>
>
> Thanks,
> Paul.
>
> > On 7 Dec 2015, at 09:59, ShinyaYoshida <bitterfoxc at gmail.com> wrote:
> >
> > Hi Paul,
> > Thank you for your answer.
> >
> > I've just updated my webrev to use 9:
> > http://cr.openjdk.java.net/~shinyafox/8144675/webrev.01/
> >
> > Regards,
> > shinyafox(Shinya Yoshida)
> >
> >
> > 2015-12-07 17:31 GMT+09:00 Paul Sandoz <paul.sandoz at oracle.com>:
> >
> >> On 7 Dec 2015, at 03:45, ShinyaYoshida <bitterfoxc at gmail.com> wrote:
> >>
> >> Hi,
> >> I'd like to wait for the review, but I have a trivial question:
> >>
> >> Which @since is preferred, 1.9 or 9?
> >>
> >
> > @since 9
> >
> >
> >> For ex, at Optional#or and stream, @since 9 is used.
> >> On the other hand, at Collectors#flatMap, @since 1.9 is used.
> >>
> >
> > Feel free to update that to 9.
> >
> > I started using @9 a little while ago in anticipation of the new
> version-string scheme (http://openjdk.java.net/jeps/223). I expect there
> will be a global sweep through the code updating @since tags.
> >
> > Paul.
> >
> >
> >
>
>



More information about the core-libs-dev mailing list