Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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

    closed as primarily opinion-based by MichaelT, durron597, Ixrec, Mason Wheeler, GlenH7 Sep 5 '15 at 13:13

    Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise.If this question can be reworded to fit the rules in the help center, please edit the question. uses Streams while java.nio use Channels and buffer, The most important distinction between way and java.nio way is, how data is packaged and 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 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:

    share|improve this answer
    I find channels easier than streams. – Dummy Derp Sep 10 '12 at 2:10
    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

    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

    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
    "If you only do I/O by reading / writing large chunks, then the BufferedXxx classes might might actually reduce throughput a bit."... I do not get this point. Isn't the whole point of using BufferedXxx in the first place is so that you do IO by chunks and not single byte/charater etc and that reduces the number of system calls to the kernel? Can you please explain what exactly you meant? – Geek Jul 30 '14 at 11:28
    I am referring to the size of the actual read or write calls that an application makes. If they are all big (enough) reads and writes to / from a byte array, then they will bypass the BufferedXxx buffers and map straight to read / write calls on the underlying stream. In that specific case, BufferedXxx wrappers are not helping performance. – Stephen C Jul 31 '14 at 12:49
    I see the point you were making. Thanks for the follow-up. +1. – Geek Jul 31 '14 at 12:58

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