JDK-6999337 : java.exe fails to start if some directory names in path to java binaries contain Russian characters
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.lang
  • Affected Version: 7
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • OS: windows_xp
  • CPU: generic
  • Submitted: 2010-11-11
  • Updated: 2011-04-06
  • Resolved: 2011-04-06
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 7
7 b132Fixed
Related Reports
Relates :  
Relates :  
Description
The issue impacts JDK 7 since b116 on Windows XP 32 bit.

If path to java home directory contains some Russian characters in directory names - e.g. "C:\ArkS\������-116\", java.exe fails to start with the following diagnostics:

C:\ArkS\������-116\bin>java -version
Error occurred during initialization of VM
java.lang.UnsatisfiedLinkError: no zip in java.library.path
        at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1857)
        at java.lang.Runtime.loadLibrary0(Runtime.java:840)
        at java.lang.System.loadLibrary(System.java:1084)
        at java.lang.System.initializeSystemClass(System.java:1129)

JDK 7 b115 and earlier run successfully within the same conditions.

Comments
EVALUATION The path chain for System class initialization is roughly like vm -> System.java:initializeSystemClass() -> System.c:initProperties(props) -> PUTPROP ... PUTPROP sun.jnu.encoding .... jvm.cpp:JVM_InitProperties() -> PUTPROP(key, value) ->java_lang_String::create_from_platform_dependent_str() ->javaClasses.cpp... ->jni_util.c:NewStringPlatform() ->initializeEncoding() ->System.java:getProperty("sun.jnu.encoding") which means the jvm nees the property "sun.jnu.encoding", which is set at the early stage of the initialziation, to correctly convert the the key/value from native bytes to Java String when initializing its System property, which includes the boot path for loading all libraries. The change for #6977738 in System.java as showed below ... props = initSystemProperties(); ... private static Properties initSystemProperties() { Properties props = new Properties(); initProperties(props); // initialized by the VM sun.misc.VM.saveAndRemoveProperties(props); return props; } actually makes the System.props not available for access until the initialization is done, so during the initializationthe jvm has to fall back to use iso8859-1 for the bytes->String conversion, which obviously ends up of corrupting the boot.class.path if there is any non-iso8859-1 characters embedded. In fact, it does not only mess up the path property, all properties that have non iso8859-1 characters in it, such as a Japanese path in user.home/name/dir, -Dxyz=Chinese, will be corrupted.
15-02-2011

EVALUATION The reason that "zip" library cannot be loaded is that those Russian characters are not properly converted into "java.library.path" property. They all are converted to '?'s. You don't need to actually have your directory pathname contain those Russian chars. Just append some dummy Russian directory to your Windows PATH environment variable, and watch for it in the "java.library.path" property so that java.exe runs normally.
02-12-2010

EVALUATION This bug is a regression caused by the fix to 6977738. I confirmed that removing the changeset for that fix would get rid of this issue. According to Sherman, the fix might have changed the loading order of the 'zip.dll' which is needed to decode the path name that contains Russian characters. So I am assigning this issue to Mandy. In order to reproduce this issue, you need to switch the system locale to Russian in the Windows Control Panel, and also need to install the Russian keyboard layout to create a directory containing Russian characters. Either I or Sherman can help on reproducing this.
01-12-2010