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 <[email protected]>
To: Heiko Wagner <[email protected]>
CC: [email protected], [email protected]
References: <fbf17156b578423ebb162b16b2513...@heikoxp>
Heiko,
I'm copying this to the [email protected] 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
