Patch: New version of "UTF-16 to 'Win32 locale' conversions" and filenames (replacing convertion tables with Win32 API calls)

[Bryce McKinlay]

On Friday, Sep 19, 2003, at 01:56 Pacific/Auckland, Mohan Embar wrote:

> This is what I was thinking: have an interface (actually a C++ 
> abstract base
> class) called IJvWin32API and two concrete implementations: JvWin9XAPI 
> and
> JvWinNTAPI. At startup time, the runtime initializes a global 
> IJvWin32API
> pointer with one of the concrete implementations based on the 
> platform. We wouldn't
> put all of the API in here, only the ones with string-related things.
> IJvWin32API would (of course) have a UNICODE interface.
>
> This would introduce one extra level of indirection per API call, but 
> who
> cares. This would also lead to some duplication, but since we're 
> mirroring the
> OS API here, it would only be a couple of lines per method 
> implementation.

Rather than making up a C++ interface, I'd prefer to see wrappers 
around these native conversion routines implemented with a 
gnu.gcj.convert interface - or even better, java.nio.charset. Charset 
conversions need to be done in various places besides java.io.File 
(AWT, for example), and it would be great to have access to them from 
Java code. It also means we won't have to write separate code for POSIX 
and Win32 everywhere to do the character conversions. A different win32 
java.nio.charset provider could be registered at startup depending on 
whether 9x or NT is used, avoiding the extra indirection.

This is the approach I intend to take for the posix File implementation 
when time allows.

Regards

Bryce.