AW: AW: AW: Path.resolve as a static method ?

[Christian Schlichtherle]

Hi Alan,

> > I would like to detail the issue a bit more, though: I may be wrong,
> > but my impression is that the NIO.2 API lacks a common addressing
> > scheme (not to confuse with a URI scheme).
>
> That is correct, it deliberately does not mandate the URI syntax used
> by
> providers. As I think we've discussed before, federation is a bit
> outside of the scope of this API and we don't want to re-invent JNDI.

I hear this argument sometimes, but frankly I think it's void. Comparing JNDI to a federated file system API is like comparing SOAP to RESTful Web Services. JNDI surely provides the necessary abstraction to allow to address a file system, but it's not providing the typical features a user looks for in a file system API, e.g. copying a directory tree. After all, if it were, JSR 203 would not be required. And besides, it's API is simply terrible, ignoring many of the items in Joshua Bloch's "Effective Java" or whatever you might prefer as guidelines for good OOD.

I think that the objectives for the spec might be missing an important opportunity: The opportunity would be to provide a uniform API for virtual file systems, which clearly includes the need for file system federation. Java today has quite some different projects addressing this need, but none of them really covers all requirements. If JSR 203 would provide a standard means for file system federation though, these projects could focus on providing implementations of the spec which could be combined by users at runtime like I explained in my previous mail.

I think this would be a great improvement for Java users. JNDI just isn't the answer.

With best regards,
Christian Schlichtherle