RFC: Character set converters...

[Bryce McKinlay]

Per Bothner wrote:

>> How would you get data into the converter without either an extra 
>> layer of copying, or creating a new CharBuffer instance each time 
>> (via the wrap() method)? Seems to me you'd have to do one of these 
>> things for every write() call.
>
>
> Can you not allocate the CharBuffer/ByteBuffers in the
> OutputStreamWriter and InputStreamReader classes?
>
> We could define gnu.java.io.BufferedOutputStream and
> gnu.java.io.BufferedInputStream classes, which would be
> functionally equivalent to java.io.BufferedOutputStream
> and java.io.BufferedInputStream, except that they use
> direct byte buffers. Hence they don't export the old
> protected fields, but instead export a ByteBuffer.


That would work, but it complicates things a bit, and the public char[] 
variants, called by user code, would still have to copy or wrap.

With direct buffers, there is another problem, in that the encoder 
implementation itself will have to either be written in native code, or 
copy the contents of the buffer into its own array in order to 
efficiently access the data. Array-backed buffers at least provide the 
array() method to directly access the buffer without copying. Perhaps as 
a special GCJ extension we could come up with a way to wrap a direct 
buffer with an array, though.

Its unfortunate that buffers make it so difficult to access the data 
efficiently. Ideally there would be some kind of array-like language 
syntax to access them, rather than the inefficient get()/put() methods. 
We could perhaps apply peephole method specialization optimizations to 
reduce the overhead of the single-element calls, but even then, code 
written with get()/put() is not as elegant & clean as array code.

Regards

Bryce