Patrick, Alan is right in the sense that we have to estimate usefulness of each method wisely. Unfortunately your codebase (or anyone else's) might have some very specific biases and thus might not be a good sample to base conclusions upon.
We need some more data to justify this proposal. The good start could be the jdk itself -- to see if those copy-with-my-buffer methods could be useful here. -Pavel > On 27 Nov 2014, at 17:40, Patrick Reinhart <patr...@reini.net> wrote: > > >> Am 27.11.2014 um 17:57 schrieb Alan Bateman <alan.bate...@oracle.com>: >> >> On 27/11/2014 15:56, Pavel Rappo wrote: >>> Patrick, as soon as I get feedback from Alan and Paul I'll merge these >>> changes into the current version. >>> >>> 1. I wonder if it makes sense to provide an additional method where client >>> specifies CharBuffer to be used? >>> Moreover if the first argument is CharSequence then we don't even need a >>> buffer: >>> >> I would suggest starting out with the simple copy(source, target) and only >> add additional variants if there is strong need. In this case, is a variant >> that allows the intermediate buffer to be specified be something that would >> be widely used? >> >> -Alan > > In our codebase here we have variants of different buffer sizes, mostly there > are some with smaller sizes than the default I took from the Files class. To > have the copy function within the JDK instead using a separate library or > have this code written over and over again is much more important to me. > > -Patrick
