Point lambdafications in java.io

[Joe Bowbeer]

I'm not in favor. As an implementer of custom IO streams, I'm aware of the
burden that proper close() implementation adds, as well as the lack of any
uses in many contexts. You can't(*) add close and expect best effort to be
acceptable. There are unit tests, and close is expected to propagate
(right?), e.g., in concat'd and zipped and merged and filtered streams.

As Remi points out, this would also require diluting the static analysis
checks and editor warnings that are in place to ensure proper use of
Closeables. From the programmer's point of view, every Stream would have to
be treated as if it were an IO stream.

Joe
On Jun 18, 2013 6:48 PM, "Brian Goetz" <brian.goetz at oracle.com> wrote:

> I did a quick look at the code, this would be very easy to implement by
> piggybacking on top of the existing checking for stream re-use.  Just as
>
>   Stream s = ...
>   s.forEach(...)
>   s.forEach(...) // throws ISE
>
> fails because the stream is being "reused", we can have future stream
> operations fail with ISE if they are initiated after the stream is closed.
>  For the example behavior you suggest, probably anything could happen.  But
> we can make a good-faith effort to prevent future stream operations from
> proceeding (which, Mike noted, is more than a lot of the existing
> Autocloseable IO classes do.)
>
> On 6/18/2013 12:30 PM, Sam Pullara wrote:
>
>> I am very much in favor of a way to signal to the stream to relinquish
>> resources so that you don't have to exhaust it to ensure that it is cleaned
>> up. That said, without things like takeWhile() I'm not sure that there are
>> many cases where you can close the stream unless you are in an exception
>> state. What would be the semantics of something like this:
>>
>> Stream stream = list.stream();
>> stream.forEach(o -> stream.close());
>>
>> Sam
>>
>> On Jun 18, 2013, at 9:05 AM, Brian Goetz <brian.goetz at oracle.com> wrote:
>>
>>  The libraries team added the following methods to java.io and java.nio,
>>> with discussion on corelibs-dev:
>>>
>>> In java.io.BufferedReader:
>>>   Stream<String> lines()
>>>
>>> In java.nio.Files, static methods for:
>>>
>>>   CloseableStream<Path> list(Path dir) throws IOException;
>>>
>>>   CloseableStream<Path> walk(Path start, int maxDepth,
>>> FileVisitOption... options) throws IOException
>>>
>>>   CloseableStream<Path> walk(Path start, FileVisitOption... options)
>>> throws IOException
>>>
>>>   CloseableStream<Path> find(Path start,
>>>                            int maxDepth,
>>>                            BiPredicate<Path, BasicFileAttributes>
>>> matcher,
>>>                            FileVisitOption... options)
>>>         throws IOException
>>>
>>>   CloseableStream<String> lines(Path path, Charset cs) throws IOException
>>>
>>>
>>> CloseableStream simply extends Stream and AutoCloseable, making it
>>> suitable for use with try-with-resources:
>>>
>>> public interface CloseableStream<T> extends Stream<T>, AutoCloseable {
>>>     void close();
>>> }
>>>
>>> Should we consider moving AutoCloseable up to Stream and friends, and
>>> get rid of CloseableStream?
>>>
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/lambda-libs-spec-experts/attachments/20130619/586c56dd/attachment.html