<AWT Dev> RFE: Windows awt FileDialog in JDK9

[Semyon Sadetsky]

In my opinion the switching to old/new file dialog should be presented 
in more explicit way. The automatic fallback may cause unexpected 
behavior. May be it is worth to introduce a new system property to 
regulate the file dialog version.

--Semyon

On 3/9/2016 3:44 PM, Hendrik Schreiber wrote:
>> On Mar 9, 2016, at 10:45, Artem Ananiev <artem.ananiev at oracle.com> wrote:
>>
>> as far as I remember, AWT team investigated the new file dialog, when Vista was released. It looks fine, but there's an issue: it doesn't provide a way to implement
>>
>> FileDialog.setFilenameFilter(FilenameFilter filter)
>>
>> method. The chances are Microsoft has introduced new APIs for it since then, otherwise this method should be protected with a "isSupported" check.
>
> As far as I can tell, Vista still had a method called SetFilter (https://msdn.microsoft.com/en-us/library/windows/desktop/bb761826(v=vs.85).aspx) which could be used to implement this, but it was removed in Windows 7.
> The recommended replacement is SetFileTypes (https://msdn.microsoft.com/en-us/library/windows/desktop/bb775980(v=vs.85).aspx), which only accepts type patterns (I guess something like "*.exe”).
>
> This means, the current FileDialog.setFilenameFilter(..) cannot be implemented, just like Artem stated.
>
> Bummer.
>
> And frankly, making that method unavailable (even protected by isSupported), would probably annoy quite a few people.
>
> I can come up with two options to have it both ways (maintain compatibility and use the new dialog):
>
> == Option 1
>
> Use the old common dialog-based implementation, whenever setFilenameFilter() was called. Otherwise use the new implementation and document this behavior in the javadocs.
>
> == Option 2
>
> Introduce the following inner classes to FileDialog (just an outline):
>
> public static class FileType {
>      public FileType(String description, List<String> extensions);
>      // convenience constructor
>      public FileType(String description, String... extensions);
>
>      public String getDescription();
>      public List<String> getExtensions();
>      ...
> }
>
> public static class FileTypeFilter implements FilenameFilter {
>      public FileTypeFilter(List<FileType> fileTypes); // do you guys prefer collections or arrays?
>      // convenience constructors
>      public FileTypeFilter(FileType... fileTypes);
>      public FileTypeFilter(String description, String... extensions);
>      public List<FileType> getFileTypes();
>      ...
> }
>
> FileTypeFilter can easily be mapped to SetFileTypes. So when a user calls setFilenameFilter() with a FileTypeFilter as argument, we can still show the new dialog without having to modify the FileDialog API (well, except for adding two inner classes).
>
> Just like in Option 1, whenever a FilenameFilter is set, that is not also a FileTypeFilter, fall back to the old implementation.
> This behavior, obviously has to be documented.
>
>
> The drawback for both options would be, that we have to maintain an old and a new implementation. That always sucks.
>
> Cheers,
>
> -hendrik