Point lambdafications in java.io

[Joe Bowbeer]

Update:

Some of my comments were based on the assumption that all streams would be
Closeable, the way all IO streams are closeable.

The problem with adding closeable stream separately is that none of the
closeable streams' stream methods return closeable streams. That, and also
that there are no closeable primitive streams.
On Jun 19, 2013 3:36 AM, "Joe Bowbeer" <joe.bowbeer at gmail.com> wrote:

> 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/5c7c4111/attachment-0001.html