Name: rmT116609			Date: 07/22/2004


A DESCRIPTION OF THE REQUEST :
Assume the following situation on a Linux PC:
'/some_dir/some_sym_link' is a symbolic link to '/some_other_dir/some_sub_dir'
Opening '/some_dir/some_sym_link' in a JFileChooser will give back 'some_other_dir/some_sub_dir' as return value.

JUSTIFICATION :
For a stand-alone PC this is not a problem, but within a network the following situation can occur:

PC1 has a directory /usr/dir1

PC2 has no such directory but a symbolic link /usr/dir1 which points to /net_node/some_dir/dir1

Now some application server is running on PC1 and the client on PC2. If the user chooses some file from the '/usr/dir1' and hands over the address to the server, it will give '/net_node/some_dir/dir1', which might not be a valid address on PC1.

The problem is due to the 'getCanonicalFile()' method used in javax.swing.plaf.metal.MetalFileChooserUI and javax.swing.plaf.basic.BasicFileChooserUI.
New classes could be deduced just overriding the needed methods, but this is not possible due to some 'private' or 'protected' declarations. Therefore some more lengthy workarounds have to be used, which have a lower performance.


EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
It would be nice if
javax.swing.plaf.metal.MetalFileChooserUI
and
javax.swing.plaf.basic.BasicFileChooserUI
would have some flag to select between 'getCanonicalFile()' and 'getAbsoluteFile()'.
ACTUAL -
In both classes MetalFileChooserUI and BasicFileChooserUI the method 'getCanonicalFile()' is being used.
(Incident Review ID: 285826) 
======================================================================