<Swing Dev> RFR: 8182043: Access to Windows Large Icons [v7]

[Sergey Bylokhov]

On Fri, 21 May 2021 02:45:15 GMT, Sergey Bylokhov <serb at 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