• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Java NIO vs. traditional IO.

 
Sheriff
Posts: 3063
12
Mac IntelliJ IDE Python VI Editor Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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.
 
Wanderer
Posts: 18671
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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.
 
Author
Posts: 30
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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.
 
Ranch Hand
Posts: 782
Python Chrome Ubuntu
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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
Posts: 30
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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: 3063
12
Mac IntelliJ IDE Python VI Editor Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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
Posts: 18671
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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.

 
Consider Paul's rocket mass heater.
reply
    Bookmark Topic Watch Topic
  • New Topic