Support for Apple Extensions

[Michael Hall]

On Jul 9, 2013, at 5:13 AM, Michael Hall wrote:

> On Jul 5, 2013, at 6:45 AM, Alan Bateman wrote:
> 
>> On 05/07/2013 11:18, Artem Ananiev wrote:
>>> 
>>> :
>>> 
>>> What about eIO? Is it used by anybody?
>> I'm interesting in hearing about that too as it looks like FileManager defines a few things that might be more appropriate for java.awt.Desktop. Methods to access a file's type/creator codes that could easily be handled via the file system API (I think Michael Hall's FileSystemProvider might already do this).
> 
> 
> Artem Ananiev
> 
>> All the above is UI related stuff (eAWT). It should work in JDK7/8 as it worked in Apple JDK6, since the code was contributed to OpenJDK by Apple with little or no modifications. Note, however, that it is not as supported as public APIs in java.* and javax.* namespace. We don't have any plans to drop support for eAWT, but all the issues in these classes will be of lower priority by default.
>> 
>> What about eIO? Is it used by anybody?
> 
> If this project is not entirely committed to supporting some of this. I could try to add more of the eio functionality into my trz project. Would licensing be concern if I did some of it more cut and paste initially to get it in place or should I write it from scratch? I could make this project more available to others somehow. How would be best?
> 
> I am not thinking of eawt at this point. Artem says it is more supported and should be through JDK8. Although not at a high priority? That I think requires custom hooks between the api and the jdk so I don't think it could be 3rd partied if anyone wanted to? 
> 
> So it still might be wondered where it would be documented? My own opinion is that some of the eawt api's are very important to making java app's work as Mac app's. Would there be a possibility of some of it going into Desktop as was suggested?

No response back on this but I did throw something together. Definitely still needs work.
Again this is just for eio.

Javadoc
http://www195.pair.com/mik3hall/doc/us/hall/osx/eio/FileManager.html
http://www195.pair.com/mik3hall/doc/us/hall/osx/eio/FileHelper.html

It appears Oracle has applied the classpath exception to the java and CFileManager native for FileManager.
My understanding is that this is pretty good about allowing copying and relicensing.
So for most of the FileManager functionality I did just do a copy and paste.

The exception there would be for the file/creator meta data. As was mentioned my trz package already included some nio.2 support for that using a custom Mac filesystemprovider.
Actually it supports three different file attribute views, for three different api's.
 
mac_finder    with 9 different meta attributes. You didn't think color was file meta data? Set the label finder label attribute for a file to orange.
mac_ls           launch services api's. redundant for 3 of the finder api's, but still adds 9 of it's own meta attributes.
mac_cocoa   adds 26 meta attributes, redundant with a lot of what is in finder and ls and probably most of what is in the jdk posix attribute view.

 FileManager again is supposed to be functionally equivalent to the current Apple class.
I added a separate FileHelper class to accomplish two things.
First, make the use of the above attributes easier for developers who haven't had a chance to get familiar with the new nio.2 api's.
To list available trz attribute views
     public static String[] getTRZViews()
To list meta attributes for that view
    public static ArrayList<String> listAttributes(String view)

to access those attributes
   public static Object getAttribute(File f,String attr)

Will sequentially search all three supported views for the attribute, returning the first found.
The methods to actually indicate the view isn't there yet. This a little thrown together yet.

The second thing FileHelper tries to do is use the launch services meta data to help on those occasions when you want to work with a file using another application. 
For example open a html file with the default browser.
This is sort of why the mac_ls attribute view is there.

To determine applications for files…
public static File[] getApplications(File f)
The default…
public static File getDefaultApplication(File f) 

It has methods using runtime exec for the open command to pass those files to the application concerned.
Open with the default app….
public static void open(File f)
Open with preferred app…
public static void open(File f,File app)

Anyhow, I have the thing on github.
https://github.com/mik3hall/trz

If you want a project with open source support of the Apple eio.FileManager extension, this could do it.
I would also like to think it could add some value of it's own.
One possibility if you want to somehow split eawt and eio support. Or how they are handled going forward.

Michael Hall

trz nio.2 for OS X http://www195.pair.com/mik3hall/index.html#trz

HalfPipe Java 6/7 shell app http://www195.pair.com/mik3hall/index.html#halfpipe

AppConverter convert Apple jvm to openjdk apps http://www195.pair.com/mik3hall/index.html#appconverter