classpath-patches
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [cp-patches] Path proposal: java.io.PrintStream


From: Bryce McKinlay
Subject: Re: [cp-patches] Path proposal: java.io.PrintStream
Date: Sat, 24 Jul 2004 13:01:28 -0400

On Jul 24, 2004, at 5:03 AM, Jeroen Frijters wrote:

Bryce McKinlay wrote:
Jeroen Frijters wrote:

The attached patch fixes PrintStream to allow subclassing to work as
expected (and allows the Mauve PrintStream.subclass test to pass).


It seems inefficient to add yet another indirection layer. I think a
better solution would be to make the classpath PrintStream
more like the libgcj implementation, which uses the character
converter directly instead of depending on
PrintWriter/OutputStreamWriter.

I agree it isn't ideal. I wasn't even aware that libgcj had a different
implementation (sigh, why is there still so much non-essential
divergence?).

The problem with PrintStream is that the underlying character converters have not yet been merged. There was talk in the past of making these use the java.nio character APIs, but I now think that is the wrong approach, because those APIs are too heavy-weight and complex for our purposes - we don't want to have to do things in terms of nio Buffers from the stream and writer classes. Instead, I think the encoding APIs in libgcj and classpath should be merged, keeping them as simple and efficient as possible. The java.nio.charset implementations could then be written to use the underlying classpath encoder API.

I still want to commit my patch because I don't think the additional
overhead is too big compared with the existing implementation. Hopefully
one day someone will merge the libgcj version.

OK by me, but please add a comment explaining why the wrapper is necessary, and a FIXME explaining that it should go away in the future.

Thanks

Bryce





reply via email to

[Prev in Thread] Current Thread [Next in Thread]