I have updated this webrev, now at:
http://cr.openjdk.java.net/~briangoetz/JDK-8008670.3/webrev/
These are all nonpublic implementation-only files (no public APIs) that
do not depend on the public Stream APIs.
These can go back as soon as the changes to Map and Spliterator are put
back.
On 03/12/2013 02:29 AM, Mike Duigou wrote:
Some notes:
- Copyrights update.
- The order of notes on files is the order that I read the files. It seems like
not a bad order to review them.
- package docs? Coming next?
java.util.Map::
- @since 1.8 missing for defaults
- tt/tt should be
On Mar 12, 2013, at 12:13 AM, Paul Benedict pbened...@apache.org wrote:
3) StreamShape: Javadoc should be formatted to be within 80 characters.
Hmm... that is linked to an old version.
It should be the same as:
On Mar 12, 2013, at 2:29 AM, Mike Duigou mike.dui...@oracle.com wrote:
Some notes:
- Copyrights update.
Pushed to lambda repo:
http://hg.openjdk.java.net/lambda/lambda/jdk/rev/40c0a71455d7
- The order of notes on files is the order that I read the files. It seems
like not a bad
Hi Mike,
On Mar 12, 2013, at 2:29 AM, Mike Duigou mike.dui...@oracle.com wrote:
AbstractTask::
- that describes a portion of the input - describes the he portion of the
input associated with the subtree rooted at this task.
- setRawResult() : needs better docs. Why does getRawResult
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
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
Some notes:
- Copyrights update.
- The order of notes on files is the order that I read the files. It seems like
not a bad order to review them.
- package docs? Coming next?
java.util.Map::
- @since 1.8 missing for defaults
- tt/tt should be replace with {@code}
- default methods need the
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.
I'll answer this one because we've gotten it from a few places.
This is a nice idea, and it works fine up to a certain level of
complexity. But when you have a
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
10 matches
Mail list logo