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

Martin Buchholz martinrb at google.com
Wed Feb 25 02:22:49 UTC 2009

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.


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

More information about the core-libs-dev mailing list