|
From: | David Daney |
Subject: | Re: [cp-patches] [Patch] Improve/fix gnu.java.net.LineInputStream... |
Date: | Tue, 13 Sep 2005 10:43:29 -0700 |
User-agent: | Mozilla Thunderbird 1.0.6-1.1.fc3 (X11/20050720) |
Tom Tromey wrote:
"Chris" == Chris Burdess <address@hidden> 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
[Prev in Thread] | Current Thread | [Next in Thread] |