🚀 go-pugleaf

On Sun, 13 Oct 2002 17:51:10 +0100, Owen Green wrote:

> Any (easy) home grown solutions look like they'd suffer from 
> the same frailties as all the old deprecated JDK1.x conversion
> methods, as they'd rely on assumptions about the character 
> encoding.

The java.nio package in Java 1.4 has new classes for dealing with 
encoding.  I have not tried them, but this may be what you need.

-- 
Regards,

John McGrath [TeamB]

---------------------------------------------------
Before sending me e-mail, please read:
    http://www.JPMcGrath.net/newsgroups/e-mail.html

"John McGrath [TeamB]" <ng-b@JPMcGrath.net> wrote in message
news:MPG.1816ea6e9f26b40e98ba95@newsgroups.borland.com...
> On Sun, 13 Oct 2002 17:51:10 +0100, Owen Green wrote:
>
> > Any (easy) home grown solutions look like they'd suffer from
> > the same frailties as all the old deprecated JDK1.x conversion
> > methods, as they'd rely on assumptions about the character
> > encoding.
>
> The java.nio package in Java 1.4 has new classes for dealing with
> encoding.  I have not tried them, but this may be what you need.

Should have mentioned that given that it's going towards a public
framework I was trying to keep it to within 1.3 compatibilty - limiting
it to 1.4 would probably reduce take-up.

I really can't see /why/ InputStreamReader has to over read though - I
understand that's for efficiency, but it would be nice to be given the
option.*

The Jetty servlet engine seems to have something that deals with this,
so I'm looking at their code to see if it provides any insight.

Thanks for the suggesstion,
Owen

*Unless I misunderstand it's behaviour. But, AFAICS, it will just read
in it's default buffer (8k) every time it fills, which knackers you if
you have arbitary textual and binrary content in the same stream.

"Owen Green" <owen@begonefoulmachine.kennulz.demon.co.uk> wrote in
message news:3da9a473$1@newsgroups.borland.com...
> Hi,
>
> Is there a standard idiom for situations where one wants to read both
> byte and character data from the same stream?
>
> AFAICS, InputStreamReader is the only officially mandated method of
> safely converting from one to the other*, but this will read more data
> than it actually needs from the underlying stream, which isn't
> desireable.
>

Looking at the guts of InputStreamReader, a solution may be to provide
an intermediatary buffer that drip feeds the reader with an
ultra-conservative number of bytes (say, ooh, one :). This will mean it
has to refill and reconvert much more often though, which may knacker
performance. Can't think of anything else though, short of creating a
new String, byte by byte (!).

(It also means that direct calls to read(char[]...) will break the
contract of the reader, but this will all be internal)

This seems to be straying dangerously near relying on an implementation
detail though.

Thoughts, comments and insults welcome.
Owen

"Owen Green" <owen@begonefoulmachine.kennulz.demon.co.uk> writes:

> Should have mentioned that given that it's going towards a public
> framework I was trying to keep it to within 1.3 compatibilty - limiting
> it to 1.4 would probably reduce take-up.

Only in the short term. 1.4.x adds so much to Java that people have
requested (wheelmouse support, JSSE/JCE etc.) that, at some point, it
will be imnpossible not to use it for produiction code anyway.

"Tor Iver Wilhelmsen (TeamB)" <tor.wilhelmsen@ergo.no> wrote in message
news:uadldftol.fsf@ergo.no...
> "Owen Green" <owen@begonefoulmachine.kennulz.demon.co.uk> writes:
>
> > Should have mentioned that given that it's going towards a public
> > framework I was trying to keep it to within 1.3 compatibilty -
limiting
> > it to 1.4 would probably reduce take-up.
>
> Only in the short term. 1.4.x adds so much to Java that people have
> requested (wheelmouse support, JSSE/JCE etc.) that, at some point, it
> will be imnpossible not to use it for produiction code anyway.

Indeed - it's just a matter of when that mass take-up happens (quite
probably before I finish this, in all likliehood :).

There's lots of other neat stuff in 1.4 that will be helpful for this
(async. i/o, for instance), so I'll  be making sure those bits are
adequetly decoupled, so people have the choice.

For the time being however, I'm stuck with finding something that will
work < 1.4 :)

Thanks,
Owen