Tom Tromey wrote:
"Chris" == Chris Burdess <[EMAIL PROTECTED]> writes:
I did take the liberty of adding my own micro-optimization, in that
if the encoding is US-ASCII, we can skip using String's character
encoding system and just request hibyte of 0. I did this because a
year ago with libgcj-3.4.3 we were seeing a vast increase in speed
doing this in a different situation.
Chris> This micro-optimisation should be applied to
Chris> ByteArrayOutputStream.toString, not here.
I agree with this approach.
However, I'm not sure this optimization is correct. Strictly
speaking, we may see a byte >= 0x80, which is not ASCII. Will the
ASCII converter turn this into '?'? (I forget what happens here ... I
know Sun has been a bit lax about ASCII handling in some areas,
treating it as identical to 8859-1.)
Well I am punting on this question. We can do it later if deemed
necessary. I just committed the ByteArrayOutputStream.toString patch
without handling this special case.
I think the question for LineInputStream has to be considered in the
light the the HTTP RFC (2616). What makes sense for LineInputStream may
be different than for the more general purpose public API that is
ByteArrayOutputStream.toString.
Any non ASCII characters in the response/headers are in violation of the
RFC. So it probably does not matter what we do, what ever is
easiest/most efficient is probably best.
David Daney
_______________________________________________
Classpath-patches mailing list
Classpath-patches@gnu.org
http://lists.gnu.org/mailman/listinfo/classpath-patches