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 _______________________________________________ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
