Bug ID: JDK-8156183 Alternative needed in Java 9 for getting large file icon

Versions (Unresolved/Resolved/Fixed)

The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.

JDK 12
12Resolved

A DESCRIPTION OF THE REQUEST :
It is useful to be able to display the system icon for a file or folder. In Java 8 there are two ways to do that:

1. javax.swing.filechooser.FileSystemView.getFileSystemView().getSystemIcon(file); This retrieves only a tiny 16x16-pixel icon.

2. sun.awt.shell.ShellFolder.getShellFolder(file).getIcon(getLargeIcon). This accepts a boolean argument specifying whether to get a "small" or "large" icon, which in practice means 16x16 or 32x32.

While 32x32 isn't large by the standards of current-millennium operating systems, it is still four times the area of the best icon available via the public API, so it is useful. In my application (a media file browser), I use the ShellFolder class to get the 32x32 icon. With Java 9's module enforcement, that method is now blocked. Only the tiniest icon is available.

I request that either the sun.awt.shell package be made publicly accessible, or a new `FileSystemView` method be made available accepting some hint as to the desired size, or that would return a `List<Icon>` of all the available sizes, or that would return an instance of the new Java 9 `java.awt.image.MultiResolutionImage` representing all the available sizes, or that such a method be added to `java.awt.Desktop` or `java.awt.Toolkit` instead. Like the existing methods in Java 8, any new method needs to work for unreal folders like the Windows "Computer" and "Network" locations too.

There are several good API possibilities, and I don't care what it is or where it is, just so long as there's some way to continue to use large icons.

JUSTIFICATION :
Limiting new Java applications to displaying 16x16 icons for files is not good enough.

If there are so many images sizes then the MRI approach looks even better, if the performance drop will measured then we can add the new method which will return MRI.
11-05-2016
Sergey, The method should accept the desired image size. List of files usually uses 16x16 icon. But the line of icon in Windows may contains 16, 24, 32, 64, 96, 128, 256. So, instead if reading one small image the number of bigger images have to be loaded. According to [1] icon extraction may be time consuming operation. This especially makes sense for network drives and for icons are not cashed in the system yet. [1] https://msdn.microsoft.com/en-us/library/windows/desktop/bb761854(v=vs.85).aspx
11-05-2016
@I think a separate method is the right way to address this issue. And what we will do if there will be middle sized images? Or more than three images? It depends from the content of the image of-course but current API have nothing related to the image size(bothe methods can return the same image/ etc) . At least the usage of MRI should be investigated. @Also, this may cause a performance regression. Loading usual 16x16 file list icon on Windows will cause reading the whole set of sizes which reaches 256x256. Then probably this is what the user wants? to get the list of folder icons?
10-05-2016
getSystemIcon() returns Icon. Making it returning ImageIcon backed by the MultiResolutionImage makes sense for painting to HiRes device. But the usage mentioned in the bug is about making a query to the OS for the file icon of a certain size. One can still paint multi-res Icon to the desired size image and make a new ImageIcon, which may cause unwanted scaling. Or cast to MultiResolutionImage then call getResolutionVariants() and create ImageIcon if the required size has been found there. But doesn't these look as a workaround? And how to present this in the method spec? Also, this may cause a performance regression. Loading usual 16x16 file list icon on Windows will cause reading the whole set of sizes which reaches 256x256. Imagine someone need to show hundreds of files with icons, it will take much longer time, especially taking into account that we have single-threaded ComInvoker for folders. I think a separate method is the right way to address this issue.
10-05-2016
We can try to implement it via MultiResolutionImage, and return it from getSystemIcon().
10-05-2016