On 29.10.15 21:30, Phil Race wrote:
We should specify what happens if you pass in to get(String)
a) null
b) an unrecognised name.
Would it make sense to define string constants on FileSystemView
as otherwise people have to spell these exactly right without compiler
help ?
Also I expect (hope!) that we do not assert any privileges here so there
will be a SecurityException if the caller does not have the necessary
permissions.
That should be documented.
I find it odd that isLink(File) catches FNFE and just returns "false"
like this
was a normal file. Why is that ? In fact I find it particularly odd since
getLinkLocation() *does* throw FNFE if it does not exist.
I guess the new code should follow the rules which are used by
other methods in the same class, most of them catch FNFE and return some
default value. Also most of them returns default value if the passed
File is null. Anyway I think that NPE is better than IAE. At least we
should discuss this.
I am not sure why this methods are static unlike old/others methods().
public static Object get(String key) {}
Probably this method too flexible? What kind of use case for this
method inside the users application? How the user will know which
parameters to use in a cross-platform manner?
For example "fileChooserDefaultFolder" property already covered by
FileSystemView.getDefaultDirectory(), the "roots" is covered by getRoots().
Also the docs casually say
"a shell interpreted link" and "platform shell" without explaining
what they mean by a shell. Should this term be used at all or
should the docs describe this in some other words ?
getLinkLocation says
"Returns a file linked to the specified file if the specified file"
What that reads like to me is that you get back a link if
you pass in a regular file, whereas (I believe) you mean
the opposite.
I think you mean :
"Returns the regular file referenced by the specified link file"
I also note that one of the uses we located was of
ShellFolder.getShellFolder(File)
That internal API returns a ShellFolder but it we expose that it would
have to
be the java.io.File superclass I expect.
-phil.
-phil.
On 10/26/2015 06:51 AM, Semyon Sadetsky wrote:
Hello,
Please review fix for JDK9:
bug: https://bugs.openjdk.java.net/browse/JDK-8081722
webrev: http://cr.openjdk.java.net/~ssadetsky/8081722/webrev.00
As the solution it is suggested to have 3 new static methods in the
javax.swing.filechooser.FileSystemView class. Those methods proxy
sun.awt.shell.ShellFolder calls and it is enough to cover NetBeans
request. getShellFolder() method is not added because it returns the
ShellFolder instance which is not for public use under the proposed
approach.
The CCC request will be rework when the fix is approved.
--Semyon
--
Best regards, Sergey.
