JDK-7147066 : [macosx] FileDialog.getDirectory() returns incorrect directory
  • Type: Bug
  • Component: client-libs
  • Sub-Component: java.awt
  • Affected Version: 7u4
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • OS: os_x
  • CPU: generic
  • Submitted: 2012-02-20
  • Updated: 2012-05-05
  • Resolved: 2012-03-19
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 JDK 8
7u4 b16Fixed 8Resolved
Related Reports
Relates :  
Description
Here's the test to reproduce the issue with the latest build:

import java.awt.*;
import java.io.File;

public class OpenFile {
    public static final void main(String args[]) throws Exception{

        FileDialog openDialog = new FileDialog((Frame)null);
        openDialog.setVisible(true);

        if (openDialog.getFile() == null) {
            throw new RuntimeException("dialog cancelled");
        }

        String filename = openDialog.getFile();
        String folder = openDialog.getDirectory();
        File file = new File(folder + File.separator + filename);
        boolean exists = file.exists();
	System.err.println(" exists="+exists);
    }
}

The app simply asks user to choose any file and then create an instance of the io.File class and just prints whether the file exists or not. The test passes (that is file.exists returns true) on Apple's JDK and on Oracle's JDK before the changes for multipe-files support in FileDialog:

http://hg.openjdk.java.net/jdk7u/jdk7u-dev/jdk/rev/0e2f3e494814

Comments
SUGGESTED FIX Fixed http://hg.openjdk.java.net/jdk7u/jdk7u4-dev/jdk/rev/5a50422d53d8
06-03-2012

SUGGESTED FIX http://cr.openjdk.java.net/~dcherepanov/7147066/webrev/
28-02-2012

EVALUATION There's one more regression of the changes for the multiple file support. When user shows a SAVE dialog and then cancels the dialog, the following exception is thrown: 2012-02-28 01:45:10.836 java[11125:60b] *** -[__NSPlaceholderArray initWithObjects:count:]: attempt to insert nil object from objects[0] 2012-02-28 01:45:10.838 java[11125:60b] ( 0 CoreFoundation 0x00007fff96260fc6 __exceptionPreprocess + 198 1 libobjc.A.dylib 0x00007fff98d99d5e objc_exception_throw + 43 2 CoreFoundation 0x00007fff96209ce1 -[__NSPlaceholderArray initWithObjects:count:] + 113 3 CoreFoundation 0x00007fff96230603 +[NSArray arrayWithObject:] + 51 4 liblwawt.dylib 0x000000017378646f -[CFileDialog safeSaveOrLoad] + 429 The cause of the exception is that the code calls +[NSArray arrayWithObject:] passing nil as a parameter. We need to make sure that the dialog wasn't cancelled before calling this function.
28-02-2012

SUGGESTED FIX $ hg diff src/macosx/native/sun/awt/CFileDialog.m diff -r 8196ef701ac1 src/macosx/native/sun/awt/CFileDialog.m --- a/src/macosx/native/sun/awt/CFileDialog.m Wed Feb 15 14:21:13 2012 -0800 +++ b/src/macosx/native/sun/awt/CFileDialog.m Sun Feb 19 05:54:18 2012 +0400 @@ -215,7 +215,7 @@ NSUInteger i; for (i = 0; i < count; i++) { - jstring filename = JNFNSToJavaString(env, [[urls objectAtIndex:i] absoluteString]); + jstring filename = JNFNSToJavaString(env, [[urls objectAtIndex:i] path]);//absoluteString]); (*env)->SetObjectArrayElement(env, returnValue, i, filename); (*env)->DeleteLocalRef(env, filename); }
20-02-2012

EVALUATION After the patch for the multiple-files support, the native code starts to return -[NSURL absoluteString] but the Java upper-level isn't ready to handle the URL strings and the file dialog mistakenly starts to return "*file:/localhost*/path_to_file" as the selected directory.
20-02-2012