AW: AW: AW: Path.resolve as a static method ?
Alan.Bateman at oracle.com
Sat Dec 11 12:39:14 PST 2010
Christian Schlichtherle wrote:
> 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.
I'm not exactly sure where you are coming from on this but there is a
provider interface so that you can replace (or interpose on) the default
file system provider. That will allow you to install your virtual file
system that supports federation and delegation to other providers (which
I think is what you are asking for). Whether it uses JNDI for compound
names is up to you. Out of the box, the default provider is not a
virtual file system provider. It uses the platform's syntax for locating
files with a view to being interoperable with native applications. If
there are other providers installed then they use their own path syntax.
We have not attempted to mandate the path syntax used by custom
providers, or define a compound naming syntax.
More information about the nio-discuss