Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

Of the three

  • BufferedReader/Writer
  • Binary Streams
  • Channels

  • which is more preferred in real life for file I/O in Java and why?
    I prefer channels for binary data to be put into file or read from and BufferedReader/Writer for String data

    share|improve this question
    add comment

    3 Answers

    java.io uses Streams while java.nio use Channels and buffer, The most important distinction between java.io way and java.nio way is, how data is packaged and transmitted.java.io deals with data in streams (one byte at a time), whereas java.nio deals with data in blocks. Processing data by the block can be much faster than processing it by the (streamed) byte but it is not as easy as streams.

    In these situation, it is better to use java.io way:

    • Files may be large but not huge. It's possible to read an entire file into memory.
    • An application reads from or writes to only a few files or network connections at the same time, ideally using only one stream at a time.
    • The application is sequential. It won't be able to do much until it's finished reading or writing a file.

    In these situation, it is better to use java.nio way:

    • An application that need to service hundreds or thousands of connections simultaneously.

    You can see the following links for further information:

    http://www.skill-guru.com/blog/2010/11/14/java-nio-vs-java-io-which-one-to-use/

    http://blogs.oracle.com/slc/entry/javanio_vs_javaio

    https://www.ibm.com/developerworks/java/tutorials/j-nio/

    http://java.dzone.com/articles/java-nio-vs-io

    share|improve this answer
        
    I find channels easier than java.io streams. –  Dummy Derp Sep 10 '12 at 2:10
    2  
    Good for you, because almost everyone (like me) say that nio programming model is complicated that traditional java io. –  Saeed Zarinfam Sep 10 '12 at 4:04
    add comment

    The answer is "It depends" - Buffered, Streaming, Blocking and Non-blocking I/O are all used for different purposes depending on what concurrency, throughput and other performance characteristics that you're after.

    share|improve this answer
    add comment

    which is more preferred in real life for file I/O in Java and why?

    It should really be a matter of function rather than preference.

    • You use Readers and Writers for character oriented data (which requires encoding and decoding), Input/OutputStreams for byte-oriented data, and Binary streams if the data encodes binary data.

    • You use the BufferedXxx classes if you need to I/O at the granularity of a character or byte. They are a simple way to avoid the serious performance problems that can occur if you do lots of byte-at-a-time read and write syscalls.

    • If you only do I/O by reading / writing large chunks, then the BufferedXxx classes might might actually reduce throughput a bit. You can either use plain readers/writers/streams (with big char[] or byte[] buffers), or Channels and XxxBuffers. The latter are potentially faster, but the APIs are more awkward.

    • You use Channels if you need low overheads, and/or do specialised things such as "selecting" from multiple streams, scatter / gather, and memory mapped file access.

    As you can see, the different APIs is designed for different purposes. In some use-cases there is overlap, in others only one API is fit for the purpose.


    The problem with developing a "preference" for one style of I/O over another is that it leads to bad software; i.e. either code that is inefficient where I/O efficiency is needed, or overly complicated where I/O efficiency should not be a concern.

    share|improve this answer
    add comment

    Your Answer

     
    discard

    By posting your answer, you agree to the privacy policy and terms of service.

    Not the answer you're looking for? Browse other questions tagged or ask your own question.