[Fwd: Re: Unicode support in Java JRE on Windows]

[Martin Buchholz]

On Wed, Feb 25, 2009 at 03:46, Heiko Wagner <heiko.wagner at apis.de> wrote:
> Martin,
>
> thanks for your explanation. As I am fighting against WIN32 API, for over
> ten years, I can understand what you are pointing out. I usually also have
> the bad feeling the WIN32 API wins the fight almost all the time. Despite my
> great admiration for our fellow japanese friends, who have achieved great
> zen mastership in painlessly using software that has some issues in a
> unicode environment, I wonder if there is any way of contributing/suggesting
> some changes without a bunch of jdk team members getting mad at me? ;-)

You can start by fixing the JDK one piece at a time.
My personal favorite is command line, both java's own
in the launcher, and when starting subprocesses.
If you fix ProcessImpl.c to use CreateProcessW,
I will be your reviewer.  There are already comments there
to get you started.

    /* Java and Windows are both pure Unicode systems at heart.
     * Windows has both a legacy byte-based API and a 16-bit Unicode
     * "W" API.  The Right Thing here is to call CreateProcessW, since
     * that will allow all process-related information like command
     * line arguments to be passed properly to the child.  We don't do
     * that currently, since we would first have to have "W" versions
     * of JVM_NativePath and perhaps other functions.  In the
     * meantime, we can call CreateProcess with the magic flag
     * CREATE_UNICODE_ENVIRONMENT, which passes only the environment
     * in "W" mode.  We will fix this later. */

    ret = CreateProcess(0,           /* executable name */

Apparently, "We" means "you".

Martin

> Regards
> Heiko
>
> -----Original Message-----
> From: hotspot-dev-bounces at openjdk.java.net
> [mailto:hotspot-dev-bounces at openjdk.java.net]On Behalf Of Martin
> Buchholz
> Sent: Mittwoch, 25. Februar 2009 03:23
> To: Naoto Sato
> Cc: hotspot-dev at openjdk.java.net; Core-Libs-Dev
> Subject: Re: [Fwd: Re: Unicode support in Java JRE on Windows]
>
>
> Part of the history here is that the JDK used to continue supporting
> windows 98 for many years, longer than Microsoft itself!
> With that support having been dropped, it is much easier to make
> changes like this (switch from "A" to "W" interfaces consistently)
> but it's hard to find the enthusiasm.  Fighting with the win32 API is no
> fun.
> Many distinct jdk teams own affected interfaces, making a thorough
> fix organizationally difficult.
>
> Martin
>
> On Tue, Feb 24, 2009 at 17:54, Naoto Sato <Naoto.Sato at sun.com> wrote:
>> 4519026: (process) Process should support Unicode on Win NT
>>
>> This is a long standing known limitation, which has never been addressed
>> because it would require fairly big effort.
>>
>> Thanks,
>> Naoto
>>
>>> Subject: Re: Unicode support in Java JRE on Windows
>>> Date: Mon, 23 Feb 2009 16:14:11 -0500
>>> From: Karen Kinnear <Karen.Kinnear at Sun.COM>
>>> To: Heiko Wagner <heiko.wagner at apis.de>
>>> CC: hotspot-dev at openjdk.java.net, core-libs-dev at openjdk.java.net
>>> References: <FBF17156B578423EBB162B16B2513629 at HeikoXP>
>>>
>>> Heiko,
>>>
>>> I'm copying this to the core-libs-dev at openjdk.java.net alias, since
>>> I think the APIs you are referring to are more familiar to that team.
>>> And I've retitled it "Java JRE" so folks see the bigger picture.
>>>
>>> hope this helps,
>>> Karen
>>>
>>> Heiko Wagner wrote:
>>>>
>>>> Hi,
>>>>
>>>> I am currently investigating on a problem of the Java VM on Windows. The
>>>> VM
>>>> is started using the JNI invocation api. This works unless the path
>>>> contains
>>>> non-ansi characters. So I hacked the classpath with
>>>> addURLToAppClassLoader()
>>>> in sun.misc.Launcher. I at least could make a shared JRE installation,
>>>> started from a ansi path, find my JARs. Since one of my JARs does use
>>>> native
>>>> code I then got stuck at the System.loadLibrary() call. Hacking the
>>>> correct
>>>> path into the 'usr_paths' field into the ClassLoader did not help,
>>>> because
>>>> the actual Windows API call LoadLibrary() seems to be ansi flavour
>>>> instead
>>>> of wide char api. Would it be possible to make this two enhancements
>>>> without
>>>> hurting the Java VM spec?:
>>>>
>>>> 1) fill the property java.class.path from the env variable CLASSPATH
> with
>>>> a
>>>> call to GetEnvironmentVariableW instead of GetEnvironmentVariableA to
>>>> enable
>>>> setting the classpath with unicode characters
>>>>
>>>> 2) fill the property java.library.path and issue the actual LoadLibrary
>>>> with
>>>> appropriate wide char api
>>>>
>>>>> From a quick look at the VM source I found out, that most string
>>>>> operations
>>>>
>>>> use the ANSI C string functions.
>>>> Maybe it would be possible to use UTF-8 encoding to transfer the path
>>>> strings throu the Java VM routines to the final Windows API calls, to
>>>> avoid
>>>> large changes in the code base.
>>>>
>>>> Regards
>>>> Heiko Wagner
>>>>
>>>
>>
>>
>> --
>> Naoto Sato
>>
>
>