Java IO.pdf - Nguyen Dang Binh

Java I/O
This book will show you that not only can Java handle these two tasks with relative ease and
grace; it can do anything C and C++ can do, and a whole lot more. Java's I/O capabilities not
only match those of classic languages like C and Pascal, they vastly surpass them.
The most common complaint about Java I/O among students, teachers, authors of textbooks,
and posters to comp.lang.java is that there's no simple way to read a number from the console
(System.in). Many otherwise excellent introductory Java books repeat this canard. Some
textbooks go to great lengths to reproduce the behavior they're accustomed to from C or
Pascal, apparently so teachers don't have to significantly rewrite the tired Pascal exercises
they've been using for the last 20 years. However, new books that aren't committed to the old
ways of doing things generally use command-line arguments for basic exercises, then rapidly
introduce the graphical user interfaces any real program is going to use anyway. Apple wisely
abandoned the command-line interface back in 1984, and the rest of the world is slowly
catching up. [1] Although System.in and System.out are certainly convenient for teaching and
debugging, in 1999 no completed, cross-platform program should even assume the existence
of a console for either input or output.
The second common complaint about Java I/O is that it can't handle formatted output; that is,
that there's no equivalent of printf() in Java. In a very narrow sense, this is true because
Java does not support the variable length argument lists a function like printf() requires.
Nonetheless, a number of misguided souls (your author not least among them) have at one
time or another embarked on futile efforts to reproduce printf() in Java. This may have
been necessary in Java 1.0, but as of Java 1.1, it's no longer needed. The java.text package,
discussed in Chapter 16, provides complete support for formatting numbers. Furthermore, the
java.text package goes way beyond the limited capabilities of printf(). It supports not
only different precisions and widths, but also internationalization, currency formats,
percentages, grouping symbols, and a lot more. It can easily be extended to handle Roman
numerals, scientific or exponential notation, or any other number format you may require.
The underlying flaw in most people's analysis of Java I/O is that they've confused input and
output with the formatting and interpreting of data. Java is the first major language to cleanly
separate the classes that read and write bytes (primarily, various kinds of input streams and
output streams) from the classes that interpret this data. You often need to format strings
without necessarily writing them on the console. You may also need to write large chunks of
data without worrying about what they represent. Traditional languages that connect
formatting and interpretation to I/O and hard-wire a few specific formats are extremely
difficult to extend to other formats. In essence, you have to give up and start from scratch
every time you want to process a new format.
Furthermore, C's printf(), fprintf(), and sprintf() family only really works well on
Unix (where, not coincidentally, C was invented). On other platforms, the underlying
assumption that every target may be treated as a file fails, and these standard library functions
must be replaced by other functions from the host API.
Java's clean separation between formatting and I/O allows you to create new formatting
classes without throwing away the I/O classes, and to write new I/O classes while still using
the old formatting classes. Formatting and interpreting strings are fundamentally different
1 MacOS X will reportedly add a real command-line shell to the Mac for the first time ever. Mainly, this is because MacOS X has Unix at its heart.
However, Apple at least has the good taste to hide the shell so it won't confuse end users and tempt developers away from the righteous path of
graphical user interfaces.
2