Patch for Review: JvGetStringUTF and JvTempCString

[Bryce McKinlay]

On Tuesday, Aug 12, 2003, at 06:30 Pacific/Auckland, Tom Tromey wrote:

>>>>>> "Bryce" == Bryce McKinlay <bryce@mckinlay.net.nz> writes:
>
> Bryce> In this case (natFile*), I think there is a better
> Bryce> approach. Since the path of a given File object never changes,
> Bryce> we can cache the path in UTF format when each File object is
> Bryce> constructed.
>
> That makes sense.
>
> However, I'd prefer to see the UTF data lazily computed.  That way
> there's minimal overhead in the (not uncommon) case where no low-level
> operation is actually performed on the File.

It occurs to me that in most of the cases where no low level operation 
is done, the File object probable came from a File.listFiles() or 
something similar. In which case, we already have the filename in its 
native encoding and don't need to convert it again.

> BTW we should probably use the default encoding, and not UTF, for file
> names and the like.  Your approach makes that simpler.

Yeah. I am toying with the idea of a "StringConverter" class to help 
with conversions back and forth between java.lang.String and C-style 
null terminated strings in the platform's encoding. It would use our 
fast native UTF-8 conversion code in the UTF8 case and fall back on 
java.nio.charset or gnu.gcj.convert in other cases. What do you think?

Regards

Bryce.