JDK-4458949 : JFileChooser under Webstart behaves differently than without Webstart
  • Type: Bug
  • Component: deploy
  • Sub-Component: webstart
  • Affected Version: 1.0.1
  • Priority: P4
  • Status: Closed
  • Resolution: Fixed
  • OS: windows_2000
  • CPU: x86
  • Submitted: 2001-05-15
  • Updated: 2001-11-28
  • Resolved: 2001-11-28
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.
Other
1.0.1 02Fixed
Description

Name: tn108358			Date: 05/15/2001


java version "1.3.0_02"
Java(TM) 2 Runtime Environment, Standard Edition (build
Java HotSpot(TM) Client VM (build 1.3.0_02, mixed mode)

JFileChooser filechooser = new JFileChooser("c:\\");
executing this line works fine in 'normal' java.
Having this line in webstart does not work fine. First an javaw.exe - No Disk..
error occurs with the statement
"ther is no disk in the drive. please insert a disk into drive A:.".

Basically when constructing a JFileChooser using webstart it first looks at the
A drive (and to mij E: drive which is a zip drive). Running this without
webstart does not cause these errors..
(Review ID: 123768) 
======================================================================

Comments
CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: 1.0.1_02 FIXED IN: 1.0.1_02 INTEGRATED IN: 1.0.1_02 VERIFIED IN: 1.0.1_02
31-08-2004

WORK AROUND Name: tn108358 Date: 05/15/2001 well when the error occurs you can click on cancel or continue. eventually the filechooser pops up and works correctly.... ====================================================================== There is an workaround by Steve: // This class is necessary due to an annoying bug on Windows NT where // instantiating a JFileChooser with the default FileSystemView will // cause a "drive A: not ready" error every time. I grabbed the // Windows FileSystemView impl from the 1.3 SDK and modified it so // as to not use java.io.File.listRoots() to get fileSystem roots. // java.io.File.listRoots() does a SecurityManager.checkRead() which // causes the OS to try to access drive A: even when there is no disk, // causing an annoying "abort, retry, ignore" popup message every time // we instantiate a JFileChooser! // // Instead of calling listRoots() we use a straightforward alternate // method of getting file system roots. import javax.swing.filechooser.*; import java.io.*; import java.util.*; import java.lang.reflect.Method; class WindowsAltFileSystemView extends FileSystemView { private static final Object[] noArgs = {}; private static final Class[] noArgTypes = {}; private static Method listRootsMethod = null; private static boolean listRootsMethodChecked = false; /** * Returns true if the given file is a root. */ public boolean isRoot(File f) { if(!f.isAbsolute()) { return false; } String parentPath = f.getParent(); if(parentPath == null) { return true; } else { File parent = new File(parentPath); return parent.equals(f); } } /** * creates a new folder with a default folder name. */ public File createNewFolder(File containingDir) throws IOException { if(containingDir == null) { throw new IOException("Containing directory is null:"); } File newFolder = null; // Using NT's default folder name newFolder = createFileObject(containingDir, "New Folder"); int i = 2; while (newFolder.exists() && (i < 100)) { newFolder = createFileObject(containingDir, "New Folder (" + i + ")"); i++; } if(newFolder.exists()) { throw new IOException("Directory already exists:" + newFolder.getAbsolutePath()); } else { newFolder.mkdirs(); } return newFolder; } /** * Returns whether a file is hidden or not. On Windows * there is currently no way to get this information from * io.File, therefore always return false. */ public boolean isHiddenFile(File f) { return false; } /** * Returns all root partitians on this system. On Windows, this * will be the A: through Z: drives. */ public File[] getRoots() { Vector rootsVector = new Vector(); // Create the A: drive whether it is mounted or not FileSystemRoot floppy = new FileSystemRoot("A" + ":" + "\\"); rootsVector.addElement(floppy); // Run through all possible mount points and check // for their existance. for (char c = 'C'; c <= 'Z'; c++) { char device[] = {c, ':', '\\'}; String deviceName = new String(device); File deviceFile = new FileSystemRoot(deviceName); if (deviceFile != null && deviceFile.exists()) { rootsVector.addElement(deviceFile); } } File[] roots = new File[rootsVector.size()]; rootsVector.copyInto(roots); return roots; // } // return null; } class FileSystemRoot extends File { public FileSystemRoot(File f) { super(f, ""); } public FileSystemRoot(String s) { super(s); } public boolean isDirectory() { return true; } } }
31-08-2004

EVALUATION fixed in 1.0.1_02. ###@###.### 2001-11-28 This bug is actually caused by swing bug 4264750 (fixed in JRE 1.4.0) We installed our own java web start security manager, causing the swing bug 4264750 on all applications launched by java web start. Upgrading to JRE 1.4+ will fix this problem. ###@###.### 2002-04-24
24-04-2002