• Post Reply Bookmark Topic Watch Topic
  • New Topic

Java NIO vs. traditional IO.

 
Greg Charles
Sheriff
Posts: 3010
12
Firefox Browser IntelliJ IDE Java Mac Ruby
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Are the new classes meant to totally take the place of the old java.io package, or do they both have their uses? For most of the work I have done, blocking I/O is fine.
 
Jim Yingst
Wanderer
Sheriff
Posts: 18671
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
Ron Hitchens
Author
Ranch Hand
Posts: 30
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
Pho Tek
Ranch Hand
Posts: 782
Chrome Python Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
Ron Hitchens
Author
Ranch Hand
Posts: 30
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
Greg Charles
Sheriff
Posts: 3010
12
Firefox Browser IntelliJ IDE Java Mac Ruby
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
That is interesting. Have they been abandoned entirely, or will they make an appearance in a future JVM?
 
Jim Yingst
Wanderer
Sheriff
Posts: 18671
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
From this interview with the J2SE 1.4 product manager and engineering lead:
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.
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!