[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