I found around 30 usages of copy all data from a reader to an appendable or writer like this within the jdk itself:   StringBuilder sb = new StringBuilder(); // appendable   char[] buf = new char[1024];   int n;   while ((n = reader.read(buf)) >= 0) {       sb.append(buf, 0, n);   } or   Writer writer = ....   char[] buf = new char[1024];   int n;   while ((n = reader.read(buf)) >= 0) {       writer.write(buf, 0, n);   } Also in our code base with around 5 million lines of code we got a lot of copy from a readable/reader to a writer or appendable... Cheers, Patrick Am 28.10.2017 um 20:57 schrieb Roger Riggs:

Hi Patrick,

Sounds like a good idea to me.

Do you have any suggestions for concrete implementations that may benefit from specialized implementations?

As a 'push' API, an implementation will necessarily have to allocate a buffer and read characters and then append them to the appendable.  I don't remember if a 'pull' API was considered for streams in which the dest could provide its own buffer to the reader and benefit from one less copy of the bytes.

Thanks, Roger

On 10/28/2017 10:05 AM, Patrick Reinhart wrote:

...

Hi There,

Based on the *transferTo* Method on the InputStream I would propose to introduce a default method on the Readable interface. In that way the method can be used for all existing implementations of Readable and still be implemented in a special way by a individual implementer.

    /**

     * Reads all characters from this readable and writes the characters to      * the given appendable in the order that they are read. On return, this      * readable will be at end its data.      * <p>      * This method may block indefinitely reading from the readable, or      * writing to the appendable. The behavior for the case where the readable      * and/or appendable is <i>asynchronously closed</i>, or the thread      * interrupted during the transfer, is highly readable and appendable      * specific, and therefore not specified.      * <p>      * If an I/O error occurs reading from the readable or writing to the      * appendable, then it may do so after some characters have been read or      * written. Consequently the readable may not be at end of its data and      * one, or both participants may be in an inconsistent state. That in mind      * all additional measures required by one or both participants in order to      * eventually free their internal resources have to be taken by the caller      * of this method.      *      * @param  out the appendable, 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 18.3      */     default long transferTo(Appendable out) throws IOException {     ....     }

Cheers Patrick