JDK-6203271 : File.exists() does not recognize directories/files in ISO-8859
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.io
  • Affected Version: 2.0
  • Priority: P2
  • Status: Closed
  • Resolution: Not an Issue
  • OS: solaris
  • CPU: sparc
  • Submitted: 2004-12-02
  • Updated: 2012-01-11
  • Resolved: 2006-03-10
Related Reports
Relates :  
Description
JFileChooser does not select directories/files in European language. Please see the attached test java class. 

On Solaris machines, we could set this env first
%setenv LANG iso_8859_1
or %setenv LC_ALL iso-8859-1

then run
%java TestFilePath

It shows
./       ../   Gef?hl  L��nder/ 

Here is the question, is there any way I could set Locale in the application so JFileChooser could display European language directories and files?

If no, how to set env Locale on windows and mac?

We prefer to get it done in application instead of letting users set env.

THanks,

Jun


========================================================

Here is a simple test case which shows the limitation when running in a C locale on Unix.

import java.io.*;

public class LS {
    public static void main(String[] args) throws Exception {
        File[] files = new File(".").listFiles();
        for (File f : files) {
            System.out.print(f.getName());
            if (!f.exists()) {
                System.out.print("\t[File not found!]");
            }
            System.out.println();
        }
    }
}

Comments
EVALUATION File.listFiles() interprets file names based on the platform's default character set, not the locale. Locale and charsets are two related, but different concepts. Locale.setDefault() will set the locale for the instance of the VM, but there is no equivalent method (such as Charset.setDefault()) to set the character set. To modify the character set used by a Java program, you must set the encoding before the VM is launched. It would be technically very difficult to modify the jdk to support dynamic update of the charset on the command-line or at any other time during program execution. Among other things, the VM would have to constantly translate between its charset and the platform's default encoding, new JNI APIs would need to be introduced, etc. Closing this issue as "not a bug".
10-03-2006

EVALUATION Reassigning to classes_io. The question posed in the description could be rephrased as: Why doesn't it help to call Locale.setDefault(Locale.ENGLISH) first thing in the main() method of the example program? The File.listFiles() method seems to ignore the default locale if set at runtime.
02-03-2006

EVALUATION This is not a bug, but a limitation of the default locale on some operating systems. See explanation below. It should not affect usage on current versions of Windows, as they use Unicode for file names. If there is a reason why this bug should not be closed, then please reassign it to classes_io instead. The limitation affects the java.io.File.listFiles() method. See the Description section for a much simpler test case. Longer explanation: "On MacOS X and Windows, the operating system effectively uses Unicode directly for all filenames, so there is never any doubt as to how to convert a filename into a Java String. On Unix systems other than MacOS X, a filename is just a bag of bytes, and there is no obvious way to convert those bytes to Java chars. ISO-8859-1 is just one popular encoding. So on such systems, we have to trust the user to set the locale correctly. Solaris systems installed with all the defaults have a default locale where only ASCII is understood. Once upon a time, one could argue that the default encoding should be ISO-8859-1, but the emergence of UTF-8 and the Euro character have killed that idea. Bottom line: JFileChooser can't possibly do what you want it to do. This is a Solaris problem, not a Java problem." ###@###.### 2004-12-02 20:26:48 GMT
02-12-2004