sorry, forget the updated webrev
http://cr.openjdk.java.net/~ssadetsky/8081722/webrev.01/
On 10/30/2015 12:07 PM, Semyon Sadetsky wrote:
Hello Phil,
On 10/29/2015 9:30 PM, Phil Race wrote:
We should specify what happens if you pass in to get(String)
a) null
b) an unrecognised name.
Yes. I forget this.
Would it make sense to define string constants on FileSystemView
as otherwise people have to spell these exactly right without
compiler help ?
That is a good service for developers. But in our case the key strings
may vary because they depends on the implementation. It is not a
strong API. Also this methods will be used rarely just in several apps
like NetBeans and probably will be spell once only. But if you think
that it is really mandatory I'm ready to rework the fix.
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.
OK, added.
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.
It seems to me more convenient. If file is a link one can try to
query the real location using getLinkLocation(). Just to avoid too
many try-catch blocks. Then getLinkLocation() throws FNFE if the
location of the link is wrong not the link file itself.
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 ?
I'm trying to indicate difference with a file system link. I think
"shell" is a common term in computing. For example GUI desktop is a
shell. If I write "desktop interpreted link" will it require
explaining anyway?
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"
+1
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.
Sorry, but what sense to have getShellFolder(File) returned the same
File object? In those usages getShellFolder() just a handle to execute
ShellFolder.isLink() or ShellFolder.getLinkLocation(). Those methods
now available in FileSystemView class.
-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
