Pure Danger TechAlex Miller’s technical blog

1. Tuomas Kiviaho Oct 23 2008 / 1am

   I’ve been a bit skeptic how JSR 203 this number one of it’s major components turns out to be. I my self am more exited about numbers 2 and 3 but I hope still than Apache Commons VFS would be obsoleted by number one.

   I was afraid that we get yet another not so satisfying reimplementation such as java.util.logging.
2. Alan Oct 23 2008 / 2am

   Thanks Alex - this is a good taster for this part of the API. In the binary download there are more examples in the $JDK_HOME/sample/nio/file directory that may be useful.

   One nit, is that you use “~/Music” in one or two examples on the assumption that you are getting shell-like expansion. I assume you are on Linux or Unix, and in that case, ‘~’ is a valid character to have in a file name isn’t expanded by the file system — eg: Paths.get(”~”).createFile() will create a file named “~” in the current directory rather than fail because your home directory exists.

   Personally, I find it useful to do a static import of StandardOpenOption.* to keep the code that opens files a bit shorter.
3. Buddy Casino Oct 23 2008 / 3am

   At last, Java has a useful filesystem API. And it only took us ~50 felt years. I can hardly contain my feelings… *sniff*
4. Mittal Oct 23 2008 / 8am

   good stuff…
5. Alex Oct 23 2008 / 8am

   Thanks Alan - I made some tweaks based on your suggestions.
6. Anonymous Oct 23 2008 / 8am

   shouldn’t stream.close(); be mp3s.close()?
7. Alex Oct 23 2008 / 9am

   @Anonymous: Right on. Fixed.
8. Walter Oct 23 2008 / 2pm

   Seems odd that Path would have methods to get, e.g., an OutputStream. There are plenty of ways to open a file, why would they encumber Path with all of them or (alternately) declare some to be better than others? Seems to suck in a lot of otherwise unnecessary type linkage. Convenient if that’s your use case, though.

   Do illegally named Paths barf during creation or during access?
9. Bruce Oct 23 2008 / 6pm

   new StandardWatchEventKind[ ENTRY_CREATE, ENTRY_DELETE, ENTRY_MODIFY]

   or

   new StandardWatchEventKind[] {ENTRY_CREATE, ENTRY_DELETE, ENTRY_MODIFY}

   ??
10. Alex Oct 23 2008 / 8pm

    @Walter: I’d say opening a file is an awfully common use case. There are really only a few basic ways to open access to a file - the classic Input/OutputStreams of course, and the new SeekableByteChannel which works from ByteBuffers.

    When you create a path (from a Filesystem or the helper Paths class), if the path is invalid it will throw an InvalidPathException (unchecked). The rules defining what paths are invalid depends on the underlying file system (and possibly the file store as well).

    @Bruce: right on. This is why I ask for feedback… :) And also why I don’t write code in a text editor anymore. Fixed!
11. Orion Letizi Oct 25 2008 / 3pm

    Have there been discussions about how to mock this stuff up for tests? One of the things that chaps me about the existing java filesystem api is that they are all concrete classes and very difficult to mock up for unit tests.
12. Alex Oct 25 2008 / 9pm

    @Orion: I’ve actually had discussions about that with various folks over the last couple years. Because the underpinnings of the new file API are based on the concept of pluggable filesystems, there is actually the potential for an enormous amount of support.

    For instance, you could build a virtual file system that actually worked in-memory so that as your tests wrote to files, they were not actually touching disk, which of course means that it’s easy to clean up, easy to write tests that don’t depend on the runtime filesystem environment, and easy to avoid things like Windows file locking madness. If I recall correctly, no such thing will ship with the jdk but someone has already built a proof of concept.

All content © 2005-2008 by Alex Miller

Entries RSS Comments RSS Java 7 RSS Music RSS