From emmanuel.castro at laposte.net Thu Dec 9 13:20:02 2010 From: emmanuel.castro at laposte.net (Emmanuel Castro) Date: Thu, 9 Dec 2010 22:20:02 +0100 Subject: Path.resolve as a static method ? Message-ID: I am often tempted to use the following pattern : Path path=Paths.get("dir1/a") path.getParent().resolve("b") It returns dir1/a A problem occurs when path=Paths.get("a") I await "b", but I obviously get an happy NullPointerException I have to encapsulate my call to resolve() into a static method: static Path safeResolve(Path mainPath, Path other) { if (mainPath == null) return other; else mainPath.resolve(other); } and a variant for safeResolve(Path mainPath, String other). I think that this method should be standard, maybe in the Paths class. Your advice? Emmanuel CASTRO From Alan.Bateman at oracle.com Fri Dec 10 09:31:05 2010 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 10 Dec 2010 17:31:05 +0000 Subject: Path.resolve as a static method ? In-Reply-To: References: Message-ID: <4D0263D9.1000907@oracle.com> Emmanuel Castro wrote: > I am often tempted to use the following pattern : > Path path=Paths.get("dir1/a") > path.getParent().resolve("b") > It returns dir1/a > A problem occurs when path=Paths.get("a") > I await "b", but I obviously get an happy NullPointerException > > I have to encapsulate my call to resolve() into a static method: > static Path safeResolve(Path mainPath, Path other) { > if (mainPath == null) return other; > else mainPath.resolve(other); > } > > and a variant for safeResolve(Path mainPath, String other). > > I think that this method should be standard, maybe in the Paths class. > > Your advice? > > Emmanuel CASTRO > We need a resolveSibling (or better named) method as it is very common to need to resolve against the parent. In the mean-time, a possible workaround is path.resolve("../b").normalize(). -Alan. From christian at schlichtherle.de Sat Dec 11 10:32:23 2010 From: christian at schlichtherle.de (Christian Schlichtherle) Date: Sat, 11 Dec 2010 19:32:23 +0100 Subject: AW: AW: AW: Path.resolve as a static method ? In-Reply-To: <4D027F52.3040604@oracle.com> References: <4D0263D9.1000907@oracle.com> <001701cb9890$f3d116b0$db734410$@de> <4D026685.7050407@oracle.com> <001d01cb9898$9653db00$c2fb9100$@de> <4D027F52.3040604@oracle.com> Message-ID: <000001cb9961$c1955d60$44c01820$@de> 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 From Alan.Bateman at oracle.com Sat Dec 11 12:39:14 2010 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sat, 11 Dec 2010 20:39:14 +0000 Subject: AW: AW: AW: Path.resolve as a static method ? In-Reply-To: <000001cb9961$c1955d60$44c01820$@de> References: <4D0263D9.1000907@oracle.com> <001701cb9890$f3d116b0$db734410$@de> <4D026685.7050407@oracle.com> <001d01cb9898$9653db00$c2fb9100$@de> <4D027F52.3040604@oracle.com> <000001cb9961$c1955d60$44c01820$@de> Message-ID: <4D03E172.6050401@oracle.com> 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. -Alan