[Fwd: Re: Unicode support in Java JRE on Windows] (original) (raw)
Naoto Sato Naoto.Sato at Sun.COM
Wed Feb 25 01:54:42 UTC 2009
- Previous message: hg: jdk7/tl/langtools: 6498938: Faulty comparison of TypeMirror objects in getElementsAnnotatedWith implementation
- Next message: [Fwd: Re: Unicode support in Java JRE on Windows]
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
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
- Previous message: hg: jdk7/tl/langtools: 6498938: Faulty comparison of TypeMirror objects in getElementsAnnotatedWith implementation
- Next message: [Fwd: Re: Unicode support in Java JRE on Windows]
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]