Some questions and comments

Alan Bateman Alan.Bateman at oracle.com
Wed Aug 24 14:32:10 PDT 2011


Kasper Nielsen wrote:
> Hi,
>
> I am trying to implement a simple in-memory FileSystem for some 
> testing I am doing. And I've made a small mixed list of questions and 
> comments.
>
> 1)
> perhaps the equals and compare method should note that
> /foo/./xxx != /foo/xxx
Maybe, but more generally we need to think about whether the 
specification should say more about how "." and ".." (or equivalent) 
should be handled.

>
> 2)
> There are no description of what happens when you give a null object 
> to any of the methods in Path. For example, does endWith(null) return 
> false or throws an NullPointerException. I know this is minor details, 
> but no implementations of Path is available in the standard src.jar.
> So I have too try each method to see what happens when I give it a 
> null object (or download the Openjdk).
>
> This is probably not an issue for ordinary users, but for people 
> trying to implement the interface it is a bit annoying.
It's in the package description under "General Exceptions".


>
> 3)
> Shouldn't Paths.get("").iterator().next() throw NoSuchElementException?
The empty path is defined in the spec to consist of a one name element, 
that is empty, so this next() should return the empty path in this case.


> so it is consistent with Paths.get("/").resolve("").iterator().next();
>
> 4)
> I know this is a bit to late now, but the warning on Path
>
> This interface is only intended to be implemented by those developing 
> custom file system implementations. Methods may be added to this 
> interface in future releases.
>
> Is there any reason why an Abstract base class wasn't used instead of 
> an interface?
This came up several times during the development when Path was defined 
as an abstract class. Once it became clear that extension methods had a 
high chance of going into jdk8 (as part of the lambda effort) then we 
changed it to an interface.

>
> 5)
> Path.subpath() does not include an description in 
> IllegalArgumentException for the default Path providers.
> This is especially annoying because the implementation is not included 
> in src.jar.
> So you have to start guessing what the problem is. Is my endIndex 
> larger then size, or is there something else wrong.
IllegalArgumentException is specified to be thrown "if beginIndex is 
negative, or greater than or equal to the number of elements. If 
endIndex is less than or equal to beginIndex, or larger than the number 
of elements".  What additional information would you suggest for the 
description? Is this related to paths that contain "." as a name element?

>
> 6)
> Default users of FileVisitor should print more some context if null is 
> returned from any of the methods in FileVisitor
> If I return a null from a method in FileVisitor to walkFileTree. I get 
> the following exception
> Exception in thread "main" java.lang.NullPointerException: FileVisitor 
> returned null
>     at java.util.Objects.requireNonNull(Objects.java:226)
>     at java.nio.file.FileTreeWalker.walk(FileTreeWalker.java:72)
>     at java.nio.file.Files.walkFileTree(Files.java:2585)
>     at java.nio.file.Files.walkFileTree(Files.java:2618)
>     at xxxx
>
> It does not indicate which method or class that returned a null. At 
> least something like this should be possible
> fileWalker.getClass().getCanonicalName()+ "." + "visitFile()" returned 
> null
>
> Also there are no description on FileVisitor about returning null values.
It doesn't make sense for a FileVisitor method to return null and the 
walkFileTree method is specified to throw NPE if a visitor method 
returns null. Or maybe you are just asking that the NullPointerException 
have more detail to help find a bug?

>
> 7)
> Would be nice with a Files.isDirectoryEmpty(Path p);
> Right now I am using Files.newDirectoryStream(p).iterator().hasNext() 
> which it kind of ugly
You would be better with something like:

    static boolean isEmpty(Path dir) throws IOException {
        try (DirectoryStream<Path> stream = Files.newDirectoryStream(dir)) {
            return !stream.iterator().hasNext();
        }
    }

to ensure that the directory is closed.

-Alan



More information about the nio-discuss mailing list