Note however that it's not just about blocking vs. non-blocking. Even with blocking, channels are often considerably faster than streams. E.g. if I want to copy a file from one location to another using a FileInputStream and FileOutputStream, I need to read bytes from the InputStream into a byte buffer managed by the JVM, and then transfer those bytes to the OutputStream. Using two FileChannels though, I can basically tell the system to transfer bytes directly from one location to the other using native code and hardware, without the overhead of copying things in and out of JVM-managed memory. So it's worth looking into NIO any time your I/O is slow - even if you don't want to use non-blocking features.
No, NIO is not a replacement for the traditional I/O classes in java.io. It's an alternate approach using different abstractions and with different goals.
If the traditional I/O classes work for you, great, use them - they're not going away any time soon. But there are some things that only NIO can do and some things that NIO does better. The inverse is also true.
There are many tools in the box, use the one that's best for the job.
2.10 Are there any existing specifications that might be rendered obsolete, deprecated, or in need of revision as a result of this work?
We are not proposing to deprecate the current java.io APIs, but we do hope that most developers will eventually migrate to the new APIs.
The proposed parsing and formatting APIs will duplicate some of the functionality already provided by the java.text package. This duplication is acceptable because the new APIs are intended to be efficient and easy to use for common, simple situations, while the java.text APIs were designed for maximal generality and flexibility.
Scott: A scanf/printf-like feature was one of the things we intended to put into 1.4, but due mostly to time constraints we were not able to get it done. It's a highly-requested feature, so look for it in a future release.