This is the mail archive of the
java-patches@gcc.gnu.org
mailing list for the Java project.
Re: Patch for Review: JvGetStringUTF and JvTempCString
- From: Tom Tromey <tromey at redhat dot com>
- To: Bryce McKinlay <bryce at mckinlay dot net dot nz>
- Cc: gnustuff at thisiscool dot com, java-patches at gcc dot gnu dot org
- Date: 11 Aug 2003 18:06:55 -0600
- Subject: Re: Patch for Review: JvGetStringUTF and JvTempCString
- References: <9901AB28-CC59-11D7-8F3E-003065F97F7C@mckinlay.net.nz>
- Reply-to: tromey at redhat dot com
>>>>> "Bryce" == Bryce McKinlay <bryce@mckinlay.net.nz> writes:
Bryce> It occurs to me that in most of the cases where no low level operation
Bryce> is done, the File object probable came from a File.listFiles() or
Bryce> something similar. In which case, we already have the filename in its
Bryce> native encoding and don't need to convert it again.
Yeah, in this situation we can construct a new File and initialize
the native bits immediately. But I think we still want lazy
computation for other cases.
Bryce> Yeah. I am toying with the idea of a "StringConverter" class to help
Bryce> with conversions back and forth between java.lang.String and C-style
Bryce> null terminated strings in the platform's encoding. It would use our
Bryce> fast native UTF-8 conversion code in the UTF8 case and fall back on
Bryce> java.nio.charset or gnu.gcj.convert in other cases. What do you think?
Sounds reasonable to me.
Tom