FileSystemProvider

[Michael Hall]

> On Aug 1, 2021, at 1:35 PM, Alan Bateman <Alan.Bateman at oracle.com> wrote:
> 
> On 01/08/2021 16:17, Michael Hall wrote:
>> :
>> An older one. I was just thinking on this though. My own Default provider is pretty much pass through. I think it was required for me to add my own attribute classes. If these attribute classes could be added directly to the existing platform Default I could eliminate the need to override provider. This might eliminate some of these security concerns and startup timing issues. Possibly there might be other security concerns for Default extensions (plugins?). But it would get me out of the startup process.
>> I haven’t double checked yet to see if I could figure out a way to do so now without jdk changes.
> I think you mentioned in a mail a long time ago that the motivation was creator codes. As I understand it, these were deprecated more than 10 years ago in macOS 10.6. That said, if they are still relevant then I assume they are maintained as extended attributes, meaning using the UserDefinedAttributeView may provide to get to them if the format is documented.
> 
> -Alan

Creator codes are included in a couple different API’s that I provide attributes for. There is a fair amount of redundancy. But I provide attributes for Cocoa, Launch Services, Extended Attributes and Finder file API’s for OS/X. I don’t know if it provides anything essential that Java doesn’t already provide. But it does demonstrate a mechanism through the nio API’s for developers to get to native API’s that Java has not opted to provide. For example Launch Services can provide the default application associated with a file or a list of Applications that can be used. Someone might find a use for something there. I think I probably had some extended attribute support before Java provided it.
But from the issues I have run into there might be a concern for anyone else in the future attempting to override the default provider. Extending the platform provider in some way might be an easier way to accomplish this having less collision with JDK bootstrapping code.