Hi Chris,
> Am 08.12.2014 um 15:17 schrieb Chris Hegarty <chris.hega...@oracle.com>:
>
> Again, just for completeness...
>
> Some feedback from Paul Sandoz, to be explicit about the "openness" of the
> streams on return. "Does not close either stream."
>
> /**
> * Reads all bytes from this input stream and writes the bytes to the given
> * output stream in the order that they are read. On return, this input
> * stream will be at end of stream. Does not close either stream.
> * <p>
> * This method may block indefinitely reading from the input stream, or
> * writing to the output stream. The behavior for the case that the input
> * and/or output stream is <i>asynchronously closed</i>, or the thread
> * interrupted during the transfer, is highly input and output stream
> * specific, and therefore not specified.
> * <p>
> * If an I/O error occurs reading from the input stream or writing to
> * the output stream, then it may do so after some bytes have been read or
> * written. Consequently the input stream may not be at end of stream and
> * one, or both, streams may be in an inconsistent state. It is strongly
> * recommended that both streams be promptly closed if an I/O error occurs.
> *
> * @param out the output stream, non-null
> * @return the number of bytes transferred
> * @throws IOException if an I/O error occurs when reading or writing
> * @throws NullPointerException if {@code out} is {@code null}
> *
> * @since 1.9
> */
> public long transferTo(OutputStream out) throws IOException
>
> -Chris.
Looks good to me,
I guess if there are no further change requests on that method we could look at
the transfer methods for Readable/Appendable. Here we could put a transferTo
method as a default method on the Readable interface or what do you think?
-Patrick
