JDK-8191706: Proposal to add Reader::transferTo(Writer)
Hi there out a the review [1] for JDK-8066870, that will need some more working on, I created this specific issue to add an transferTo method to the java.io.Reader as it seems more clear as of the similarity to java.io.InputStream.transferTo(java.io.OutputStream) in terms of the API. To start the discussion I got the proposed API: /** * Reads all characters from this reader and writes the characters to the * given writer in the order that they are read. On return, this reader * will be at end of the data. This method does not close either reader * or writer. * <p> * This method may block indefinitely reading from the reader, or * writing to the writer. The behavior for the case where the reader * and/or writer is <i>asynchronously closed</i>, or the thread * interrupted during the transfer, is highly reader and writer * specific, and therefore not specified. * <p> * If an I/O error occurs reading from the reader or writing to the * writer, then it may do so after some characters have been read or * written. Consequently the reader may not be at end of the data 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 writer, non-null * @return the number of characters transferred * @throws IOException if an I/O error occurs when reading or writing * @throws NullPointerException if {@code out} is {@code null} * * @since 10 */ public long transferTo(Writer out) throws IOException { .... } -Patrick [1] http://mail.openjdk.java.net/pipermail/core-libs-dev/2017-November/050064.ht...
Hi Patrick, This looks fine from my point of view. It exactly mirrors InputStream.transferTo(OutputStream) with which I expect everyone will concur. Thanks, Brian On Nov 21, 2017, at 11:56 AM, Patrick Reinhart <patrick@reini.net> wrote:
Hi there out a the review [1] for JDK-8066870, that will need some more working on, I created this specific issue to add an transferTo method to the java.io.Reader as it seems more clear as of the similarity to java.io.InputStream.transferTo(java.io.OutputStream) in terms of the API.
To start the discussion I got the proposed API:
/** * Reads all characters from this reader and writes the characters to the * given writer in the order that they are read. On return, this reader * will be at end of the data. This method does not close either reader * or writer. * <p> * This method may block indefinitely reading from the reader, or * writing to the writer. The behavior for the case where the reader * and/or writer is <i>asynchronously closed</i>, or the thread * interrupted during the transfer, is highly reader and writer * specific, and therefore not specified. * <p> * If an I/O error occurs reading from the reader or writing to the * writer, then it may do so after some characters have been read or * written. Consequently the reader may not be at end of the data 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 writer, non-null * @return the number of characters transferred * @throws IOException if an I/O error occurs when reading or writing * @throws NullPointerException if {@code out} is {@code null} * * @since 10 */ public long transferTo(Writer out) throws IOException { .... }
-Patrick
[1] http://mail.openjdk.java.net/pipermail/core-libs-dev/2017-November/050064.ht...
Looks good. On 11/21/2017 2:56 PM, Patrick Reinhart wrote:
Hi there out a the review [1] for JDK-8066870, that will need some more working on, I created this specific issue to add an transferTo method to the java.io.Reader as it seems more clear as of the similarity to java.io.InputStream.transferTo(java.io.OutputStream) in terms of the API.
To start the discussion I got the proposed API:
/** * Reads all characters from this reader and writes the characters to the * given writer in the order that they are read. On return, this reader * will be at end of the data. This method does not close either reader * or writer. * <p> * This method may block indefinitely reading from the reader, or * writing to the writer. The behavior for the case where the reader * and/or writer is <i>asynchronously closed</i>, or the thread * interrupted during the transfer, is highly reader and writer * specific, and therefore not specified. * <p> * If an I/O error occurs reading from the reader or writing to the * writer, then it may do so after some characters have been read or * written. Consequently the reader may not be at end of the data 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 writer, non-null * @return the number of characters transferred * @throws IOException if an I/O error occurs when reading or writing * @throws NullPointerException if {@code out} is {@code null} * * @since 10 */ public long transferTo(Writer out) throws IOException { .... }
-Patrick
[1] http://mail.openjdk.java.net/pipermail/core-libs-dev/2017-November/050064.ht...
Here's the implementation and test.. http://cr.openjdk.java.net/~reinhapa/reviews/8191706/webrev.00 -Patrick Am 21.11.2017 um 23:07 schrieb Brian Goetz:
Looks good.
On 11/21/2017 2:56 PM, Patrick Reinhart wrote:
Hi there out a the review [1] for JDK-8066870, that will need some more working on, I created this specific issue to add an transferTo method to the java.io.Reader as it seems more clear as of the similarity to java.io.InputStream.transferTo(java.io.OutputStream) in terms of the API.
To start the discussion I got the proposed API:
/** * Reads all characters from this reader and writes the characters to the * given writer in the order that they are read. On return, this reader * will be at end of the data. This method does not close either reader * or writer. * <p> * This method may block indefinitely reading from the reader, or * writing to the writer. The behavior for the case where the reader * and/or writer is <i>asynchronously closed</i>, or the thread * interrupted during the transfer, is highly reader and writer * specific, and therefore not specified. * <p> * If an I/O error occurs reading from the reader or writing to the * writer, then it may do so after some characters have been read or * written. Consequently the reader may not be at end of the data 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 writer, non-null * @return the number of characters transferred * @throws IOException if an I/O error occurs when reading or writing * @throws NullPointerException if {@code out} is {@code null} * * @since 10 */ public long transferTo(Writer out) throws IOException { .... }
-Patrick
[1] http://mail.openjdk.java.net/pipermail/core-libs-dev/2017-November/050064.ht...
Looks good. Of course a corresponding CSR will need to be filed and eventually approved. Thanks, Brian On Nov 21, 2017, at 2:33 PM, Patrick Reinhart <patrick@reini.net> wrote:
Here's the implementation and test..
http://cr.openjdk.java.net/~reinhapa/reviews/8191706/webrev.00
-Patrick
Am 21.11.2017 um 23:07 schrieb Brian Goetz:
Looks good.
Created https://bugs.openjdk.java.net/browse/JDK-8191737 Any additions welcome -Patrick Am 21.11.2017 um 23:41 schrieb Brian Burkhalter:
Looks good.
Of course a corresponding CSR will need to be filed and eventually approved.
Thanks,
Brian
On Nov 21, 2017, at 2:33 PM, Patrick Reinhart <patrick@reini.net <mailto:patrick@reini.net>> wrote:
Here's the implementation and test..
http://cr.openjdk.java.net/~reinhapa/reviews/8191706/webrev.00 <http://cr.openjdk.java.net/%7Ereinhapa/reviews/8191706/webrev.00>
-Patrick
Am 21.11.2017 um 23:07 schrieb Brian Goetz:
Looks good.
On 21/11/2017 19:56, Patrick Reinhart wrote:
Hi there out a the review [1] for JDK-8066870, that will need some more working on, I created this specific issue to add an transferTo method to the java.io.Reader as it seems more clear as of the similarity to java.io.InputStream.transferTo(java.io.OutputStream) in terms of the API.
The updated proposal looks good. One minor nit on the javadoc is that it says "end of the data". The existing read methods use "end of the stream" so best to keep that consistent. -Alan.
Webrev and CSR updated accordingly... -Patrick Am 22.11.2017 um 09:23 schrieb Alan Bateman:
On 21/11/2017 19:56, Patrick Reinhart wrote:
Hi there out a the review [1] for JDK-8066870, that will need some more working on, I created this specific issue to add an transferTo method to the java.io.Reader as it seems more clear as of the similarity to java.io.InputStream.transferTo(java.io.OutputStream) in terms of the API.
The updated proposal looks good. One minor nit on the javadoc is that it says "end of the data". The existing read methods use "end of the stream" so best to keep that consistent.
-Alan.
On 22/11/2017 18:36, Patrick Reinhart wrote:
Webrev and CSR updated accordingly...
-Patrick
Spec and implementation looks good. -Alan
participants (4)
-
Alan Bateman
-
Brian Burkhalter
-
Brian Goetz
-
Patrick Reinhart