I/O deals with the input and output of data from a Java application. How Java handles I/O functionality has evolved over of the years and here we'll take a brief look at what I/O means to Java and how it has changed through various releases.

Streams

First let's take a moment to look at what we mean by an I/O stream. An I/O stream is the flow or data from an input source to an output destination. This could take the form of a reading or writing to a file, to memory, a database, or peripherals (e.g., keyboard, mouse).


Typcially you can think of stream as being either binary based (i.e., machine readable bytes) or character based (i.e., human readable). The classes in the Java api that deal with streams tend to reflect the differences between those two types of streams.

The other main aspect to the I/O apis are how they deal with the underlying filesystem. Making the job of dealing with files independently of the platform is a key aspect of the Java I/O.

The First Java I/O

In the beginning Java only had the java.io api to deal with input and output functionality. This api dealt with how streams of data can be input and output in a java application. It provides classes like FileInputStream, FileOutputStream, FileReader, FileWriter for low level I/O where single bytes or characters can be read or written to and from a file. It also classes for a more efficient buffered approach to dealing with data streams with classes like BufferedInputStream, BufferedOutputStream, ByteArrayInputStream, ByteArrayOutputStream.

New I/O

With the release of Java 1.4 a new input out api appeared - java.nio. This provided faster input/output functionality and some new features around file locking and character sets. This was brought about from JSR 51 - New I/O apis for the Java Platform. It's goal was to provide faster buffering for binary and character streams, character set convertors, platform independent I/O exceptions and to overhaul the filesystem interface.

Another New I/O

Next came Java 7 and another overhaul to the way Java handled I/O with respect to the underlying filesystem.

If you look at the JSR created for the new I/O api to handle interaction with the filesysytem - JSR 203 More New I/O APIs for the Java Platform (NIO.2) - you will see the reasons behind the change:

• the java.io.File class is inconsistent in the way it handles filenames across different operating systems, it's inefficient in accessing file attributes, it limits access to filesystem specific functionality and some of its methods do not throw informative errors when something goes wrong.
• to build on the work done in the first new I/O api around providing scalable and fast I/O.

So, we come to NIO.2, a new API to improve the way Java interacts with the filesystem. This does not means that everything that has gone before is now obsolete. Using buffered (or unbuffered) streams created from java.io can still as valid today as it ever was. In fact the I/O apis that exist today are meant to complement each other.

Note: For code that relies heavily on the old java.io.file class there is a new method called toPath which can be used to construct a path instance. For example,

java.nio.file.Path p = file.toPath();