Java Reference
In-Depth Information
import java.io.InputStreamReader;
public class JavaInput {
public static void main(String[] args) {
System.out.println("What is your name, user?");
BufferedReader br = new BufferedReader(new InputStreamReader(System.in));
String name;
try {
name = br.readLine();
} catch (IOException e) {
name = "?";
e.printStackTrace();
} finally {
try { br.close(); } catch (IOException e) { e.printStackTrace(); }
}
System.out.println("Welcome, " + name);
}
}
You might be bothered by the presence of the try-catch blocks and the occurrence of the
InputStreamReader , as well as the BufferedReader , which makes another appearance.
Don't despair, however, as the design choices behind this, together with arcane names such as
InputStreamReader , will all become clear in the following sections. The reason why Java's input/
output model looks somewhat daunting at first is because it is based on so-called “I/O streams.” A
stream is simply an abstraction of a particular input source (any kind) or an output destination (also
of any kind), meaning that streams can represent files, a program console, other programs, memory
locations, or even hardware devices. Depending on the input source or output destination accessed,
streams can support a variety of data formats, such as raw bits and bytes, but also characters, primi-
tive data types, and even complete objects. Some streams will just pass on data, whereas others will
perform some transformations. The key point, however, is that at their core, streams all represent a
sequence of data. While this stream-based model can be somewhat verbose in the beginning, a great
advantage is that they offer a unified model to deal with input/output, meaning that if you know
how to send output to a stream with a file as its destination, you also know how to output data to
the user console or to a device stream.
Even better news for beginning Java programmers is that, since Java 7, new features were added
that greatly simplify the examples above. Sadly, these additions have also made the I/O landscape in
Java slightly more chaotic. In Java SE 1.4, a new “Non-Blocking IO” API—oftentimes called NIO
and referred to as “new I/O”—was added to the language to complement the existing I/O facilities.
In Java 7, extensions were added in the form of NIO2 to offer a new, more sensible file system API.
However, since backward-compatibility is a strong design goal behind Java, existing file I/O meth-
ods remained supported, so that many code samples, books, tutorials, and real-life code still apply
“legacy I/O” API features. Is this a problem? Not really, except for the fact that you, the beginning
Java programmer, will have to deal with both APIs, hence the illustrating examples above. The gen-
eral recommendation for new projects is to use as much NIO2-based code as possible, but reverting
back to the legacy API where necessary is fine. In fact, the Java language designers foresaw this issue
and created a set of intercompatibility methods to quickly switch between the two, as you will see
later.
Search WWH ::




Custom Search