[Fwd: Re: Unicode support in Java JRE on Windows]
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:
> 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".
> -----Original Message-----
> From: hotspot-dev-bounces at openjdk.java.net
> [mailto:hotspot-dev-bounces at openjdk.java.net]On Behalf Of Martin
> 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
> 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.
>>> 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>
>>> 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,
>>> Heiko Wagner wrote:
>>>> I am currently investigating on a problem of the Java VM on Windows. The
>>>> is started using the JNI invocation api. This works unless the path
>>>> non-ansi characters. So I hacked the classpath with
>>>> 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
>>>> code I then got stuck at the System.loadLibrary() call. Hacking the
>>>> path into the 'usr_paths' field into the ClassLoader did not help,
>>>> the actual Windows API call LoadLibrary() seems to be ansi flavour
>>>> of wide char api. Would it be possible to make this two enhancements
>>>> hurting the Java VM spec?:
>>>> 1) fill the property java.class.path from the env variable CLASSPATH
>>>> call to GetEnvironmentVariableW instead of GetEnvironmentVariableA to
>>>> setting the classpath with unicode characters
>>>> 2) fill the property java.library.path and issue the actual LoadLibrary
>>>> appropriate wide char api
>>>>> From a quick look at the VM source I found out, that most string
>>>> 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
>>>> large changes in the code base.
>>>> Heiko Wagner
>> Naoto Sato
More information about the core-libs-dev