classpath-patches
[Top][All Lists]
Advanced

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

Re: [cp-patches] [Patch] Improve/fix gnu.java.net.LineInputStream...


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




reply via email to

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