I'm reading Ivan Horton's Java 2 JDK 5 edition. I just went through the chapters on reading and writing files. He ony covers the new nio classes (FileChannels, ByteBuffers and the various view buffers) and states that he won't cover using streams directly because the new nio methodolgy will supercede using streams directly.
After learning the new nio stuff, I can see where this might be advantages to use for very complex file I/O. However this seems like it is very complex for simple file I/O.
Consider the example of having a files with a series of variable length strings seperated by a delimiter character (the pipe(|) for example). You want to write a program that goes through the file and pulls out each individual string. It's a pretty simply proposition to use a FileInputStream and StreamTokenizer to pull out the individual strings.
Using nio means using a FileChannel, ByteBuffer, and CharBuffer. It is much more complex. Also, because any individual string can be longer than your ByteBuffer (imagine a string that is 20K long), you have to implement your own additional buffering.
Is Ivan mistaken when he states that the new nio file i/o will supercede using streams directly? I can't imagine someone choosing to use nio instead of simple streams for the example given above. But if that was the case, then why would Ivor completely ignore file I/O using InputStreams, OutputStreams, Readers and Writers? [ September 06, 2005: Message edited by: Todd Johnson ]
Be very careful about what you draw from this book. Have a look at the Amazon reviews for this edition to get an idea about how people have reacted to it. And I completely agree with Jesper about this NIO-vs-Streams pronouncement. java.nio is not intended as a replacement for java.io, but rather as an alternative in some situations.