[Ron]: I'm not entirely sure either what happens on a platform where native file mapping is not supported. I would assume that the map() call on FileChannel would throw an IOException since it would not be able to create a mapping. I'm not sure either - the book I just read didn't really address this point.
However I note that the API doesn't say anything at all about the possibility of map() being
completely unsupported. They could easily have declared that map() may throw UnsupportedOperationException, for example - but they didn't. Or they could've provided a canMap() method returning a boolean - but again, they didn't. It sounds to me like on any platform with a Java 1.4 JVM implementation, you can expect to be able to invoke map() on a valid FileChannel and have it return a working MappedByteBuffer.
However, the API is very picky about what behavior is and is not guaranteed for mapped files. Only a few things are explicitly guaranteed. One is that if/when you call the force() method on a MappedByteBuffer, any changes you've made to the buffer will be written to the file. (They may or may not have been written already.) Also even if you don't explicitly call force(), it's claimed that changes will "eventually" be written to the file. I don't know that I'd trust this though. Most other details of "mapped" file behavior are explicitly
not guaranteed. E.g. if some other process starts working with the same file, there's no guarantee whenther changes by one process will be visible to another process. I suspect it's much like multithreaded access to any shared resource without proper synchronization different threads/processes may see different local copies of data, and the
thread that completes its job last may well completely undo whatever changes were made by the previous thread. Ugh. I suppose if you're going to map() a file
you should really acquire a FileLock on it first - but there again, there are few guarantees that such locks will be respected by other processes. It's really up to the operating system.
I think that the answer to Pho Tek's question is that yes, certain features of java.nio can be a real problem if you're trying to make a reliable cross-platform solution, and you unknowingly rely too much on features which are not guaranteed to work everywhere. Though to be fair - if your MappedByteBuffer doesn't catch the changes some user just made to a critical file using a text editor, it's not usually your problem if the program breaks. Silly users should know better.
Practically speaking, many of the biggest uses of NIO are in servers, where this is less of a problem. You don't have to worry as much about making sure your program works on all possible server platforms - just
this one. Ummm, usually. And if someone is running other processes that interfere with your mapped file, you can expect the sysadmin to take responsibility for having the appropriate person killed.
For a product that you really need to be as cross-platform as possible while also benefiting from NIO's strengths where possible, you may need to write two versions of some critical parts or the system, and provide the user with some way specify whether or not to use things like file mapping. My guess is that this won't really be an issue very often, but it's probably worth keeping the idea in the back of your mind when analyzing a system - NIO may limit portability.