<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
Hello Phil,<br>
<br>
<div class="moz-cite-prefix">On 10/29/2015 9:30 PM, Phil Race wrote:<br>
</div>
<blockquote cite="mid:563265D5.8010205@oracle.com" type="cite">
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
<div class="moz-cite-prefix">We should specify what happens if you
pass in to get(String)<br>
a) null<br>
b) an unrecognised name.<br>
<br>
</div>
</blockquote>
Yes. I forget this.<br>
<blockquote cite="mid:563265D5.8010205@oracle.com" type="cite">
<div class="moz-cite-prefix"> Would it make sense to define string
constants on FileSystemView<br>
as otherwise people have to spell these exactly right without
compiler help ?<br>
<br>
</div>
</blockquote>
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.<br>
<blockquote cite="mid:563265D5.8010205@oracle.com" type="cite">
<div class="moz-cite-prefix"> Also I expect (hope!) that we do not
assert any privileges here so there<br>
will be a SecurityException if the caller does not have the
necessary permissions.<br>
That should be documented.<br>
</div>
</blockquote>
OK, added.<br>
<blockquote cite="mid:563265D5.8010205@oracle.com" type="cite">
<div class="moz-cite-prefix"> I find it odd that isLink(File)
catches FNFE and just returns "false" like this<br>
was a normal file. Why is that ? In fact I find it particularly
odd since<br>
getLinkLocation() *does* throw FNFE if it does not exist.<br>
</div>
</blockquote>
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.<br>
<blockquote cite="mid:563265D5.8010205@oracle.com" type="cite">
<div class="moz-cite-prefix"> Also the docs casually say<br>
"<span class="new">a shell interpreted link</span>" and
"platform shell" without explaining<br>
what they mean by a shell. Should this term be used at all or<br>
should the docs describe this in some other words ?<br>
<br>
</div>
</blockquote>
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?<br>
<blockquote cite="mid:563265D5.8010205@oracle.com" type="cite">
<div class="moz-cite-prefix"> getLinkLocation says<br>
<pre><span class="new"> "Returns a file linked to the specified file if the specified file"
</span></pre>
<span class="new">What</span> that reads like to me is that you
get back a link if<br>
you pass in a regular file, whereas (I believe) you mean<br>
the opposite.<br>
<br>
I think you mean :<br>
"Returns the regular file referenced by the specified link file"<br>
</div>
</blockquote>
+1<br>
<blockquote cite="mid:563265D5.8010205@oracle.com" type="cite">
<div class="moz-cite-prefix"> <br>
I also note that one of the uses we located was of
ShellFolder.getShellFolder(File)<br>
That internal API returns a ShellFolder but it we expose that it
would have to<br>
be the java.io.File superclass I expect.<br>
</div>
</blockquote>
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.<br>
<blockquote cite="mid:563265D5.8010205@oracle.com" type="cite">
<div class="moz-cite-prefix"> <br>
-phil.<br>
<br>
<br>
<br>
<br>
<br>
<span class="new"></span><br>
<br>
<br>
<br>
-phil.<br>
<br>
<br>
On 10/26/2015 06:51 AM, Semyon Sadetsky wrote:<br>
</div>
<blockquote cite="mid:562E2FD1.1070301@oracle.com" type="cite">
<meta http-equiv="content-type" content="text/html;
charset=utf-8">
Hello, <br>
<br>
Please review fix for JDK9:<br>
<br>
bug: <a moz-do-not-send="true" class="moz-txt-link-freetext"
href="https://bugs.openjdk.java.net/browse/JDK-8081722">https://bugs.openjdk.java.net/browse/JDK-8081722</a><br>
webrev: <a moz-do-not-send="true" class="moz-txt-link-freetext"
href="http://cr.openjdk.java.net/%7Essadetsky/8081722/webrev.00">http://cr.openjdk.java.net/~ssadetsky/8081722/webrev.00</a><br>
<br>
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
<meta http-equiv="content-type" content="text/html;
charset=utf-8">
the ShellFolder instance which is not for public use under the
proposed approach. <br>
The CCC request will be rework when the fix is approved.<br>
<br>
--Semyon<br>
</blockquote>
<br>
</blockquote>
<br>
</body>
</html>