They can coexist fine, I think. The main reason to port something to NIO classes is if you need to improve the I/O performance. The NIO classes are a bit harder to use in general, so for many applications you might as well just leave them with traditional I/O. 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.
I answered almost the same question in this thread. 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.
Read what the JSR 51 authors have to say on co-existence of both apis:-
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.
posted 15 years ago
Interestingly, the formatting and parsing API's were left out of NIO in 1.4. These are intended to be similar to printf/scanf in the C world.
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.