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.
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
