This is the mail archive of the
java@gcc.gnu.org
mailing list for the Java project.
Re: Another 646 patch and performance comparison with TOWER
- From: Tom Tromey <tromey at redhat dot com>
- To: martin dot kahlert at infineon dot com
- Cc: java-patches at gcc dot gnu dot org, java at gcc dot gnu dot org
- Date: 02 Apr 2002 14:27:17 -0700
- Subject: Re: Another 646 patch and performance comparison with TOWER
- References: <20020328125255.A23871@keksy.muc.infineon.com> <87bsd79l2g.fsf@creche.redhat.com> <20020402103506.A16798@keksy.muc.infineon.com> <87ofh1hl9q.fsf@creche.redhat.com>
- Reply-to: tromey at redhat dot com
>>>>> "Tom" == Tom Tromey <tromey@redhat.com> writes:
Tom> Why doesn't the `646' get turned into `ASCII' in getDecoder?
I tried the appended test.
With this I don't see any attempts to load a converter library.
So I think the 646 is being converted to `ASCII' internally.
I'm using my caching patch plus the small change ("return" -> "result =")
that you recommended.
Tom
public class t
{
public static void main (String[] args) throws java.io.UnsupportedEncodingException
{
for (int i = 0; i < 50; ++i)
{
byte[] r = new byte[5];
r[0] = (byte) 'a';
r[1] = (byte) 'b';
r[2] = (byte) 'c';
r[3] = (byte) 'd';
r[4] = (byte) 'e';
String s = new String (r, "646");
System.out.println (s);
}
}
}