[ http://issues.apache.org/jira/browse/HADOOP-129?page=comments#action_12374115 ]
Doug Cutting commented on HADOOP-129: ------------------------------------- Working through this more, I'm now leaning away from URI and towards a new class. It will be easier to replace with a new class, since the API can be made to resemble File. For example, we have a lot of code that calls 'new File(dir, name)' to construct a file in a subdirectory. The idiom for doing that with URI's is slightly more complicated, and would require a utility method somewhere. Similarly for file.getParentFile(), etc. So now I'm leaning towards a class named "Path" that's mostly a drop-in replacement for File, except it doesn't support FS operations like exists(), mkdir(), delete(), etc. > FileSystem should not name files with java.io.File > -------------------------------------------------- > > Key: HADOOP-129 > URL: http://issues.apache.org/jira/browse/HADOOP-129 > Project: Hadoop > Type: Improvement > Components: fs > Versions: 0.1.1, 0.1.0 > Reporter: Doug Cutting > Fix For: 0.2 > > In Hadoop's FileSystem API, files are currently named using java.io.File. > This is confusing, as many methods on that class are inappropriate to call on > Hadoop paths. For example, calling isDirectory(), exists(), etc. on a > java.io.File is not the same as calling FileSystem.isDirectory() or > FileSystem.exists() passing that same file. Using java.io.File also makes > correct operation on Windows difficult, since java.io.File operates > differently on Windows in order to accomodate Windows path names. For > example, new File("/foo") is not absolute on Windows, and prints its path as > "\\foo", which causes confusion. > To fix this we could replace the uses of java.io.File in the FileSystem API > with String, a new FileName class, or perhaps java.net.URI. The advantage of > URI is that it can also naturally include the namenode host and port. The > disadvantage is that URI does not support tree operations like getParent(). > This change will cause a lot of incompatibility. Thus it should probably be > made early in a development cycle in order to maximize the time for folks to > adapt to it. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
