On Fri, 21 May 2021 02:45:15 GMT, Sergey Bylokhov <s...@openjdk.org> wrote:
>> No, libraries are not supported. >> >> I see no contradiction here: `JFileChooser` uses Windows Shell API to >> enumerate objects and navigate the shell namespace. But it does not return >> non-file objects, does it? >> >> The new method accepts `File` object which implies it's a file system object >> rather than an arbitrary object in Windows Shell namespace which cannot be >> represented in Java. > > The JFileChooser supports the libraries since it allows navigation inside > them. It is done via ShellFolder which extends the file class. The > FileSystemView feeds the JFileChooser by the data, so it may returns > "non-file" objects. > For example the FileSystemView.getRoots() on WIndows will return "new > Win32ShellFolder2(DESKTOP)". > > Usually, when the FileSystemView gets a file object it checks that the file > is "instance ShellFolder". > For example, in the newly added method the line "sf = > ShellFolder.getShellFolder(f);" will check that the file is ShellFolder and > return it as-is without checking of file existence, and really that path may > not exist. but if it is a plain file it will check that. > > This is why I have asked about virtual folders, do we test them or we can > consider them as "not existed"? Maybe we can test this case by just reusing this method where the "sf.getIcon(largeicon)" previously used in the WindowsPlacesBar class? That old method has the special code for "folder.isLibrary()" so I assume it supported the Libraries. And if we will start to use the new method then all old tests for the JFileChooser will start to test it. ------------- PR: https://git.openjdk.java.net/jdk/pull/2875
