Replacing default FileSystemProvider

[Michael Hall]

> On Mar 22, 2021, at 3:43 AM, Alan Bateman <Alan.Bateman at oracle.com> wrote:
> 
> On 21/03/2021 23:09, Michael Hall wrote:
>> Had to review what I had. Actually, mac_xattr is one of the API”s I supported nio attributes for…
>> 
>> Map<String,Object> attrs = Files.readAttributes(p,"mac_xattr:*");
>> 			assertEquals(2,attrs.size());
>> 			assertTrue(attrs.containsKey("mac_xattr:com.apple.FinderInfo"));
>> 			byte[] finfo = (byte[])attrs.get("mac_xattr:com.apple.FinderInfo");
>> 			assertEquals(32,finfo.length);
>> 
>> There was some redundancy across API’s.
>> 
>> There is also the LaunchServices API
>> 
>> if (!((Boolean)Files.getAttribute(p,"mac_ls:application")).booleanValue()) {
>> 
>> One use is information about the default application associated with a file.
>> 
>> And mac_cocoa for the NS API family
>> 
>> assertFalse(((Boolean)Files.getAttribute(p,"mac_cocoa:NSFileBusy")).booleanValue());
>> 			assertEquals(Files.size(p),((Long)Files.getAttribute(p,"mac_cocoa:NSFileSize")).longValue());
>> 			attrs = Files.readAttributes(p,"mac_cocoa:NSFileModificationDate,mac_cocoa:NSFilePosixPermissions”);
>> 
>> I’m not sure this API driven stuff would exactly translate to a user attribute view.
> The com.apple.eio.FileManager API was an API in Apple's JDK up to JDK 6. The code came into the OpenJDK when support for macOS was added in 7u4 but it wasn't tracked as a supported/documented interface. The java.desktop module can't export non-standard APIs so this is why it has been encapsulated (and not exposed) at compile-time since Java 9

Dropping it is as I’ve said your decision. But I had code from about 6 years back to replace it in this eventuality I might as well put into place now.

> (why you've had to compile with --add-exports java.desktop/com.apple.eio=…

I don’t remember having to do this but maybe Eclipse building my app didn’t involve recompiling this code since then.

> to compile code that uses it). It it encapsulated at run-time since Java 16. Many of the features that eio.FileManager provided are superseded by standard APIs and java.awt.Desktop. My understanding is that type/creator codes are legacy and have been ignored on macOS for 10 years

Code sometimes doesn’t do away so quickly or easily. Carbon supports it. Carbon is still around. I think type/creator  were used for one thing in targeting AppleEvents, also still around, as-is AppleScript. Which I was  all right with when java dropped it’s support. That was something else I salvaged during the macport project, the Apple JSR 223 engine,  and I provide some support yet for that myself. Actually inspired by jpackage using AppleScript in setting up it’s disk image installs I have been looking to make sure my support of that is still what it should be. Some basic functionality seems to work as always. Apple security changes appear to have broken some support. I am currently looking at that.
 
> so it might not be worth spending time trying to create a file attribute view for them. But maybe you have a good use case that involves interop with code that still make use of them?
> 
> -Alan.

My remaining use of the FileManager API’s was as shown in the old bug report you mentioned. I use it as part of some code to try and determine the best platform specific place to write different types of data on OS X. Others may have different use cases. I would prefer to offer full support of the class and not pick and choose as long as it is easily enough done and it should be.

The Apple file API’s still have the type/creator methods, actually redundantly in a couple API’s I think. In providing nio API attributes again I preferred not to pick and choose but to provide as complete access to the API’s as possible. Some of it as was shown in one test case is redundant with java…

>> assertEquals(Files.size(p),((Long)Files.getAttribute(p,"mac_cocoa:NSFileSize")).longValue());

That might even have uses. Maybe you’re wondering if the java size is correct. You can easily compare it to the Cocoa NSFileSize value.Some of it is hopefully not redundant and may also have uses.

So it is not just type/creator I’m trying to preserve. But the full functionality of FileManager and also the FileManagerProvider access I did across the different OS X file API’s.
I was thinking of splitting those out into a separate GitHub project. They are currently in my trz project but that is pretty messy also including code from a couple different botched efforts to come up with a Mac WatchService. Something I have still unfortunately not successfully managed. 

I would do the new GitHub project when I know the provider code is working.

I am all right at this point if FileManager is dropped. I would just like to be able to provide my own for myself or whoever may hear about it and want to use it.

 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/nio-dev/attachments/20210322/db88e3b1/attachment.htm>