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
>
