Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-6999337

java.exe fails to start if some directory names in path to java binaries contain Russian characters

    Details

    • Subcomponent:
    • Resolved In Build:
      b132
    • CPU:
      generic
    • OS:
      windows_xp
    • Verification:
      Verified

      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.

        Issue Links

          Activity

          Hide
          naoto Naoto Sato added a comment -
          BT2: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.
          Show
          naoto Naoto Sato added a comment - BT2: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.
          Hide
          naoto Naoto Sato added a comment -
          BT2: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.
          Show
          naoto Naoto Sato added a comment - BT2: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.
          Hide
          sherman Xueming Shen added a comment -
          BT2: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.
          Show
          sherman Xueming Shen added a comment - BT2: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.

            People

            • Assignee:
              sherman Xueming Shen
              Reporter:
              asutchil Arkadiy Sutchilin (Inactive)
            • Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:
                Imported:
                Indexed: