Bug ID: JDK-4401437 JFileChooser doesn't validate [characters in] filenames

Type: Bug
Component: client-libs
Sub-Component: javax.swing
Affected Version: 1.3.0,5.0

Priority: P4
Status: Open
Resolution: Unresolved
OS: generic,windows_xp
CPU: generic,x86

Submitted: 2001-01-03
Updated: 2018-09-05


Name: krC82822			Date: 01/03/2001


15 Dec 2000, eval1127@eng -- validation of characters in filenames
can be filed as an EOU.  The latter part is documented as not being supported.
see also bug #4125509 (part 2).
------------
java version "1.3.0"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.0-C)
Java HotSpot(TM) Client VM (build 1.3.0-C, mixed mode)

JFileChooser isn't choosy enough. It:
(a) doesn't check that a filename doesn't contain any illegal characters, and
(b) doesn't check that (for file open dialogs) the file actually exists.

It's possible to do this in user code, but it's the wrong place to do it
because it makes it harder to stick to the look and feel (the text used in
the errors should be consistent across different applications on the same
platform, and different across different platforms), because the JFileChooser
insists on closing itself as soon as a button is clicked.
(Review ID: 112925) 
======================================================================

EVALUATION There are two issues here: (a) doesn't check that a filename doesn't contain any illegal characters This is certainly a valid bug. It is desirable for JFileChooser to take care of this validation in order to be correct for the platform. This will, however, require API change since we can't add this support in a backward-compatible way. (b) doesn't check that (for file open dialogs) the file actually exists. This is also something that's desirable. By adding new API, we can make this behavior completely configurable. This is worthy of a new RFE, which I've filed as 6215240. An important note: One of the things the submitter complained about that stood in the way of him implementing this behavior himself was the fact that JFileChooser closes itself when the button is pushed. In actuality, this can be avoided if the correct method is overridden. By overriding JFileChooser.approveSelection(), the developer can do whatever they want first and then decide whether or not to allow the filechooser to close. If they want it to close, they call super.approveSelection(), otherwise they return without calling it. ###@###.### 2005-1-07 19:56:22 GMT

07-01-2005

WORK AROUND Name: krC82822 Date: 01/03/2001 keep reopening the JFileChooser in a loop, do the checks yourself, displaying an error message if necessary, then reopening the JFileChooser if we're not yet happy. ====================================================================== A better workaround is to subclass JFileChooser and override the method approveSelection() to do validation and then call super.approveSelection() when happy. leif.samuelsson@Eng 2001-01-03

03-01-2001