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

Naoto Sato Naoto.Sato at Sun.COM
Wed Feb 25 01:54:42 UTC 2009


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



More information about the core-libs-dev mailing list