File System metadata

[Elliotte Harold]

Alan Bateman wrote:
> Elliotte Harold wrote:

> The attributes defined by the various views in the attribute package 
> provide access to significantly more meta-data than is possible with the 
> File class today. 

There are a few extra bits but not as much as I expected. There's a lot 
more that's out there that isn't supported by the current API.

My hope that was by supporting arbitrary names and values one could 
write platform specific code without using platform specific classes. 
For example, I want to write a program that uses Mac specific attributes 
when running on a Mac, I'll probably need classes and methods that are 
only available on Apple's VM. This means that not only do I have to 
write platform specific code. I also have to do a lot of extra work to 
allow the same code to compile and run on other platforms due to missing 
classes and methods. Not impossible, of course. I do a lot of this 
already today. A generic file metadata API that used only JDK standard 
classes and methods would be a lot easier to configure at runtime.


> Furthermore, an implementation can support additional 
> views beyond those defined in that package -- ie: a provider is not 
> limited to the attribute views defined in the attribute package. 

These will be second class citizens though. Imagine we removed the 
PosixFileAttributes and DosFileAttributes classes and associated 
methods; and relegated them to optional JDK-vendor specific extensions 
that programmers could not assume the presence of. Would you still be 
satisfied with the functionality that was available?

> Another 
> point is that one of our goals with the new API is to provide bulk 
> access to file attributes - essentially a stat-like API because too 
> often we see performance issues with applications that need to access 
> several file attributes of the same file at around the same time.

That's fine. You could of course have a generic getAttributes method 
that returned a map of all the attributes on the file on the given file 
system.

> In the zipfs sample code you'll see an example of this in action. It 
> defines ZipFileAttributeView and JarFileAttributeView that provide 
> access to zip/JAR entry specific attributes.
> 

Thanks. I'll look at that.

> The granularity of the support is at the level of a set or group of 
> attributes rather than individual attributes. To that end, the 
> FileSystem#getFileAttributeViews is the method to enumerate the 
> supported FileAttributeViews supported by the FileSystem. You can also 
> ask an underlying FileStore if it supports a given view by invoking the 
> supportsFileAttributeView method.  An implementation is minimally 
> required to support BaiscFileAttributeView and may support others 
> (including provider/implementation specific FileAttributeView types that 
> aren't defined by the attribute package).

Those are the key pieces I was missing. That makes this minimally 
possible, though you still have the problem of needing to bundle 
filesystem specific classes with your code. This runs into all sorts of 
licensing troubles, as well as extra weight for a program. It's like 
bundling a lot of the Apple-specific classes into a program just so you 
can run your MRJ invoking jar on Windows. Or you can just use reflection 
to call everything.

I now see how you're planning to support extensions, which I didn't 
before. However I still think a generic approach would be a lot cleaner 
and more elegant.


-- 
Elliotte Rusty Harold  elharo at metalab.unc.edu
Java I/O 2nd Edition Just Published!
http://www.cafeaulait.org/books/javaio2/
http://www.amazon.com/exec/obidos/ISBN=0596527500/ref=nosim/cafeaulaitA/