<Swing Dev> [9] Review Request for 8081722: Provide public API for file hierarchy provided by sun.awt.shell.ShellFolder

[Semyon Sadetsky]

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
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/swing-dev/attachments/20151030/3ed4a209/attachment.html>