On Thu, 20 May 2021 18:51:54 GMT, Alexey Ivanov <aiva...@openjdk.org> wrote:
>> So the libraries are not supported? I doubt since JFileChooser should >> support them, and supports of it is one of the reasons why we use shell >> folder to iterate the folders and do not use the javaio. > > 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"? ------------- PR: https://git.openjdk.java.net/jdk/pull/2875
