classpath
[Top][All Lists]
Advanced

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

Re: Classpath digest, Vol 1 #180 - 5 msgs


From: Takashi Okamoto
Subject: Re: Classpath digest, Vol 1 #180 - 5 msgs
Date: Tue, 26 Jun 2001 11:29:59 +0900
User-agent: Wanderlust/2.5.8 (Smooth) SEMI/1.14.3 (Ushinoya) FLIM/1.14.2 (Yagi-Nishiguchi) APEL/10.3 Emacs/20.7 (i386-debian-linux-gnu) MULE/4.1 (AOI)

At Mon, 25 Jun 2001 12:03:10 -0400,
wrote Tom:
> For instance we discovered that the String(byte[]) constructor was
> creating too much garbage if you converted a large number of
> strings.  That's because it was creating a new converter for each
> string.  So now we're looking at a way to reuse converters (the
> patch isn't in yet but probably will be soon).

Should I wait it?

> Takashi> Well, I want to add other japanese encodings like EUC-JP
> Takashi> ,Shift_JIS... Does anyone implement them? If not, I would try
> Takashi> that.
> 
> libgcj has converters for a few Japanese encodings.  If the character
> set interface were unified then Classpath could simply use these.

I see. But IMO, libgcj's Japanese converter isn't good idea because
converters are provided with native interface. If I use native
interface, I would prefer iconv. If I don't use native interface, I
prefer _Java_ converter though it may lost performance...

I also refered CharToByteEUC_JP.java and ByteToCharEUC_JP.java in
Kaffe. They are more reusable because they are separated character
tables from converter classes.

Could we migrate Kaffe's (it's GPL) code ? 
----
Takashi Okamoto








reply via email to

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