This is the mail archive of the java-patches@gcc.gnu.org mailing list for the Java project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


Hi People,

>> 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.
>
>
>This seems an excelent approach!
>The same kind of approach has been taken for SWT (see OS.java in 
>org.eclipse.internal.win32).
>
>Since MultiByteToWideChar()/WideCharToMultiByte() functions are also 
>available in NT/2000/XP, I cannot find any reason to loose time with a 
>temporary patch using a C++ interface. Therefore I shall only propose a 
>temporary patch for GCC 3.4, using A-functions.

There is one inherent problem with this approach on Windows. WinNT
and above supports UNICODE natively. Win9X does not. And WinNT
does everything internally in UNICODE. When you call the A functions
on WinNT, the OS will first convert the string to UNICODE before calling
the W function. All A calls on WinNT (which also means Win2K, WinXP,
etc.) are therefore inherently more inefficient than their corresponding W calls.

If we unconditionally implement the MultiByteToWideChar()/WideCharToMultiByte()
approach on WinNT, then we will be converting from UNICODE to
ANSI and back to UNICODE again. This seems unnecessarily wasteful,
especially since the sole reason for doing this is pandering to the Win9X OSes
which are essentially obsolete. I'd much rather use the W functions directly on
WinNT platforms, which we already know that we can't do on Win9X without
Unicows, which I agree that I'm ambivalent about. Therefore, I don't see any
way around a dual code base on Windows even with Bryce's proposal.

>The same kind of approach has been taken for SWT (see OS.java in 
>org.eclipse.internal.win32).

SWT simply implements one-to-one Java wrappers around the corresponding
OS call. This is essentially the approach that I recommend with my C++
interface idea, albeit with a uniform UNICODE interface.

-- Mohan
http://www.thisiscool.com/
http://www.animalsong.org/





Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]