Replacing default FileSystemProvider

[Michael Hall]

For some or all cases where it fails FileSystems.java

private static FileSystemProvider getDefaultProvider() {

Fails to load the class. I have been unable in testing to get the cut and pasted method to load it either. It never gets the Class. 

Double checking the bug report seems to show that jar or modular jar are the only not exploded options(?) I was hoping for a workaround that didn’t require exploded but for now I guess I’ll settle for that. 

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

You may be right here.

			Path defApp = (Path)Files.getAttribute(p,"mac_ls:default_application");
			System.out.println("default " + defApp);
			int i_type = FileManager.OSTypeToInt("TEXT");
			int i_creator = FileManager.OSTypeToInt("ttxt");
			FileManager.setFileTypeAndCreator(p.toString(),i_type,i_creator);
			defApp = (Path)Files.getAttribute(p,"mac_ls:default_application");
			System.out.println("new default " + defApp);

Gets…

default /Applications/BBEdit.app
new default /Applications/BBEdit.app

For TEXT/ttxt I expected it to change the default application to TextEdit. It didn’t.
For added value for my FileManager replacement I also came up with a FileHelper class that included some code related to the nio attributes. 


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