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

[Heiko Wagner]

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? ;-)

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
>