Alan.Bateman at Sun.COM
Mon Jul 14 04:41:04 PDT 2008
Alan Snyder wrote:
> Thanks to the article by Elliotte Harold, I have become aware of this
> work. I want to say that it is long overdue and will be much appreciated.
> I want to make a pitch for supporting fully abstract paths, that is,
> paths that are not bound to any file system or file system
> implementation. A fully abstract path is simply a sequence of names.
> Before it can be used to access a resource, it must be presented to a
> file system (which might convert it to a bound path as in the current
As Mark suggests, this probably only makes sense for paths that don't
have a root component. In that case, the path is simply a sequence of
names. In that case, the only awkward issue is how to represent those
names. If you can live with Strings (recalling that converting from the
platform representation to String may be lossy, at least on platforms
where representation is bytes) then List<String> or String, as Mark
suggests, might be okay. Since Path already implements Iterable<Path>
and defines the resolve(String) method it means you should be able to
try this out now (yes, it would be a bit inefficient but if this is
generally useful then we could define methods to import/export as a
sequence of names).
> Fully abstract paths can be useful whenever you are performing cross
> file system operations, such as mirroring. The same relative fully
> abstract path can be presented to two file systems to access resources
> that correspond by name. Fully abstract paths could also be used in a
> catalog (as might be created by a backup program), which stores
> metadata but does not contain the actual files.
I'm interested in hearing about the mirroring - are you thinking about
mirroring directory structures between file systems associated with
More information about the nio-discuss