My comments...

1) TerminalOp: When default methods are very simple (i.e., a one-liner),
you are sometimes (not always) putting the body on a new line. I think you
should use a consistent coding style and always start the body on the next
line.

2) I find X_IN and X_OUT type parameters to be disruptive to reading.
Sticking to a simple "I" and "O" would be much easier to read.

3) StreamShape: Javadoc should be formatted to be within 80 characters.

4) There are plentiful of if() statements that are not using braces. An
if() should always use braces per the published Java coding conventions.

Paul

On Mon, Mar 11, 2013 at 4:55 PM, Brian Goetz <brian.go...@oracle.com> wrote:

> I've posted an updated webrev incorporating comments received to date:
>
>    http://cr.openjdk.java.net/~briangoetz/jdk-8008670.2/webrev/
>
>
>
> On 2/21/2013 2:16 PM, Brian Goetz wrote:
> > At:
> >    http://cr.openjdk.java.net/~briangoetz/jdk-8008670/webrev/
> >
> > there is a webrev of a subset of the implementation of java.util.stream,
> > for review.  These are all new files.  None of these are public classes;
> > they are internal interfaces for the Stream library, as well as some
> > implementation classes.  This is about half the classes in the Streams
> > package.
> >
> > (The webrev includes changes to Map, but those are being reviewed
> > separately, so just ignore those.)
> >
> > We're asking people to focus their review on both the quality of API
> > specification for these internal APIs, and the quality of implementation
> > of the specified classes.  It may not be obvious how some of these work
> > until you've seen the rest of it, but do what you can.
> >
>
>

Reply via email to