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

[Semyon Sadetsky]

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

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