[Fwd: Re: Unicode support in Java JRE on Windows] (original) (raw)

Martin Buchholz martinrb at google.com
Wed Feb 25 16:05:24 UTC 2009

On Wed, Feb 25, 2009 at 03:46, Heiko Wagner <heiko.wagner at apis.de> wrote:

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

You can start by fixing the JDK one piece at a time. My personal favorite is command line, both java's own in the launcher, and when starting subprocesses. If you fix ProcessImpl.c to use CreateProcessW, I will be your reviewer. There are already comments there to get you started.

/* Java and Windows are both pure Unicode systems at heart.
 * Windows has both a legacy byte-based API and a 16-bit Unicode
 * "W" API.  The Right Thing here is to call CreateProcessW, since
 * that will allow all process-related information like command
 * line arguments to be passed properly to the child.  We don't do
 * that currently, since we would first have to have "W" versions
 * of JVM_NativePath and perhaps other functions.  In the
 * meantime, we can call CreateProcess with the magic flag
 * CREATE_UNICODE_ENVIRONMENT, which passes only the environment
 * in "W" mode.  We will fix this later. */

ret = CreateProcess(0,           /* executable name */

Apparently, "We" means "you".

Martin

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 'usrpaths' 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