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

System.load() fails to load from unicode paths

    XMLWordPrintable

    Details

    • Subcomponent:
    • Understanding:
      Cause Known
    • CPU:
      x86_64
    • OS:
      windows

      Description

      FULL PRODUCT VERSION :
      java version "1.8.0_152"
      Java(TM) SE Runtime Environment (build 1.8.0_152-b16)

      ADDITIONAL OS VERSION INFORMATION :
      Microsoft Windows [Version 10.0.15063]

      A DESCRIPTION OF THE PROBLEM :
      This is the same problem that was reported here:

      https://bugs.openjdk.java.net/browse/JDK-8017274

      But we don't agree to the conclusion.

      Locales should simply not be evaluated for loading a DLL.

      The root cause seems to be, as pointed out in JDK-8017274, that the DLL path is converted from Unicode to the character set of the console (jnu encoding), which cannot represent the characters.
      The bug is that the DLL loading is being done with the ASCII-version of the Windows API instead of using the Unicode API.
      All file access in Java (like Files.move and File.exists) is based on Unicode and uses the Unicode API of Windows. So should System.load



      STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
      1) copy a DLL to "c:\temp\my.dll"
      2) run the following code (assuming you don't have a jnu code page that can represent both eastern european and chinese characters)

          // precondition: have a DLL 'my.dll' in current working directory
          File oldname = new File( "c:\\temp\\my.dll");
          File newname = new File( "c:\\temp\\Timi\u015foara - \u4E0A\u6D77\u5E02.dll" );
          Files.move( oldname.toPath(), newname.toPath());

          if ( newname.exists() )
             System.load(newname.getAbsolutePath());


      EXPECTED VERSUS ACTUAL BEHAVIOR :
      EXPECTED -
      DLL is loaded, no exception thrown
      ACTUAL -
      java.lang.UnsatisfiedLinkError: D:\temp\Timi?oara - ???.dll: Can't find dependent libraries
      at java.lang.ClassLoader$NativeLibrary.load(Native Method)
      at java.lang.ClassLoader.loadLibrary0(Unknown Source)
      at java.lang.ClassLoader.loadLibrary(Unknown Source)
      at java.lang.Runtime.load0(Unknown Source)
      at java.lang.System.load(Unknown Source)


      REPRODUCIBILITY :
      This bug can be reproduced always.

        Attachments

          Issue Links

            Activity

              People

              Assignee:
              Unassigned Unassigned
              Reporter:
              webbuggrp Webbug Group
              Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

                Dates

                Created:
                Updated: