File System metadata
elharo at metalab.unc.edu
Mon May 26 05:35:44 PDT 2008
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?
> 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
> 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!
More information about the nio-discuss