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

[David Daney <ddaney at avtrex dot com>]

Tom Tromey wrote:
> > > > > > "Chris" == Chris Burdess <dog@bluezoo.org> 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