Unicode support in Java JRE on Windows (original) (raw)
Karen Kinnear Karen.Kinnear at Sun.COM
Mon Feb 23 21:14:11 UTC 2009
- Previous message: hg: jdk7/tl/jdk: 6806649: synchronization bottleneck when constructing Thread subclasses
- Next message: hg: jdk7/tl/jdk: 6350801: Add support for named (instead of numbered) capture groups in regular expression; ...
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
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
- Previous message: hg: jdk7/tl/jdk: 6806649: synchronization bottleneck when constructing Thread subclasses
- Next message: hg: jdk7/tl/jdk: 6350801: Add support for named (instead of numbered) capture groups in regular expression; ...
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]