DirectoryChooserUI: reduce reflective win ShellFolder API usage

[mbien]

• some internal methods are now public in FileSystemView and can be used instead of using reflection
• remove calls to ShellFolder.getShellFolder(file) entirely since there is no public equivalent still

this hopefully fixes the mysterious NPEs on windows caused by broken java.io.File instances with null paths.

fixes #7067
fixes #8040

[mbien]

this didn't seem to make a difference, removing this call allows us to remove the ShellFolder.getShellFolder(file) call site entirely, which has no public API equivalent.

There is a chance that this is the place which injected the broken java.io.File instances. If the public FileSystemView methods would have caused this, other projects would likely have noticed it too by now.

also see #8040 (comment) and #8040 (comment)

[lkishalmi]

Looks good to me. BTW, what this useShellFolder does on Windows? I see a lot of custom code around it here and in the DelegatingChooserUI as well.

Is that still relevant/useful feature to have?

[mbien]

what this useShellFolder does on Windows?

@lkishalmi I think its a special windows specific file-link, can be "Desktop", "recent files", a drive or network folder (potentially a custom file explorer shortcut).

The JDK makes it a special java.io.File, however, it was observed that something injected broken file instances with null paths. You couldn't call any method on them, including toString() without causing NPEs somewhere since that field is not nullable.

[eirikbakke]

Look OK; I assume you were testing it on Windows.

I don't have a Windows machine around at the moment, but I tested it on MacOS and at least confirmed it didn't immediately cause any problems there.

[mbien]

I assume you were testing it on Windows.

on win 10. Also on linux, but none of the methods return anything interesting on linux still #8040 (comment).

but I tested it on MacOS and at least confirmed it didn't immediately cause any problems there.

awesome, going to merge it soon