> On 26 Jan 2016, at 16:57, Tagir F. Valeev wrote:
>
> Hello!
>
> Thanks for review! Updated webrev:
> http://cr.openjdk.java.net/~tvaleev/webrev/8147505/r2/
> Removed redundant test and added a comment.
>
Thanks, it’s in my queue,
Paul.
Hello!
Thanks for review! Updated webrev:
http://cr.openjdk.java.net/~tvaleev/webrev/8147505/r2/
Removed redundant test and added a comment.
With best regards,
Tagir Valeev.
PS> Hi Tagir,
PS> StreamCloseTest.java
PS> —
PS> 181 try(Stream s = countTo(100).stream()) {
PS> 182
Hi Tagir,
StreamCloseTest.java
—
181 try(Stream s = countTo(100).stream()) {
182 s.map(x -> x).forEach(i -> {});
183 checkISE(() -> s.onClose(() -> fail("2")));
184 }
We don’t need this one, it’s redundant. The other performing the s.close() is i
thin
Hello!
Here's a webrev:
http://cr.openjdk.java.net/~tvaleev/webrev/8147505/r1/
I just added a check in AbstractPipeline.onClose and the corresponding
unit-test. To me it seems that no documentation corrections are
necessary, because "onClose" is already documented that it's
an intermediate operat
Hello!
Seems that my original letter sounds confusing due to my bad English.
Every occurrence of "idempotent" should be read as "not idempotent".
Sorry for this!
PS> We did not bother to throw ISEs from parallel/sequence/onClose
PS> primarily because they return “this” and they are kind of
PS> ha
Hi Tagir,
AutoCloseable.close states:
* However, implementers of this interface are strongly encouraged
* to make their {@code close} methods idempotent.
It’s possible we just did not consider this aspect too much in BaseStream.close
and we just lent on the "strongly encouraged”, which seems fi
Hello!
Current documentation for BaseStream.onClose() does not specify
explicitly how the stream would behave if additional close handlers
are registered after the stream is consumed or even closed. The
implementation actually allows registering the additional close
handlers after consumption or c
