RE: Patch: RFC: InputStreamReader and OutputStreamWriter

["David Daney" <ddaney at avtrex dot com>]

Bryce McKinlay wrote:
>On 10-Mar-05, at 8:03 PM, Tom Tromey wrote:
>
>> I'm not checking this in yet.
>>
>> This patch is one way to add new java.nio-aware constructors to
>> InputStreamReader and OutputStreamWriter.  It does this by adding a
>> layer of indirection, in the classic mold.
>>
>> Another approach would be to add a field to InputStreamReader and
>> OutputStreamWriter, and then have two paths in each method -- one that
>> does what the method does today, and another to forward to a Reader or
>> Writer from java.nio.
>>
>> I don't much care which one we do.  One is easier to read, the other
>> may have better performance in common situations (I didn't look).
>>
>> Sometime this year, hopefully, this code will go away or be rewritten
>> anyway, when we do the Big Classpath Merge.
>>
>> Any preferences?
>
>Another approach would be to write a gnu.gcj.convert converter which
>wraps an nio converter? That way we wouldn't incur extra overhead in
>the common case, and for nio it might even be more efficient than using
>getReader().

You mean something like this?:

http://gcc.gnu.org/ml/java/2004-09/msg00174.html

As posted above my patch doesn't quite get us to having the Charset constructors for InputStreamReader and OutputStreamWriter, but it shows the way.
 
We leave InputStreamReader mostly unchanged and change UnicodeToBytes$CharsetAdaptor to be public and then create instances of it from the InputStreamReader(InputStream, Charset) constructor.
 
The little test program in the refered to message shows us that Sun uses (last time I checked) a hybrid approach similar to this.  I think that there are performance wins to using the java.nio.Charset infrastructure as little as possible.  We should keep that in mind.
 
David Daney.