Chapter 17. Simple Input Output

  • Design Philosophy

  • The Class java.io.File

  • Keyboard I/O

  • Output

  • Wrapping Additional Output Classes

  • Input

  • Reader Wrappers

  • Inputting ASCII Characters and Binary Values

  • Input Stream Wrappers

  • Further Reading

  • Exercises

  • Some Light Relief—The Illegal Prime Number!

SCSI-wuzzy was a bus.

SCSI-wuzzy caused no fuss.

SCSI-wuzzy wasn't very SCSI, was he?

Designing input/output (henceforth “I/O”) libraries is a lot harder than it might appear. There have been some spectacular blunders in the past. One language, Algol 60, gave up on I/O altogether, leaving it out of the language specification and making it an implementation-defined detail! Pascal has the deficiency that you can't test for end-of-file until you have read from the file, distorting all while loops that control input. The C library gets() call to read a string from a stream is probably the biggest single security hole in the history of computing.

It was responsible for the November 1988 Morris Worm that permeated all the then 50,000 (!) hosts on the Internet.[1] Classic Fortran I/O is so ugly because John Backus's team decided to reuse an existing IBM 704 assembler library instead of designing their own language support.

Getting to Know Java I/O

We'll start off by giving you an idea of what the problems are with Java I/O (we'll get all the gripes off our chest in one go). Then we'll look at the purpose of the java.io and mention the names of some of the many packages that make up the Java I/O library.

Java I/O problems

So what are the problems with Java I/O? It boils down to this: it is a very large library and it took six release with four different implementations to get it mostly right. Excessive use of the wrapper design pattern confuses rather than helps. It relies too much on the C I/O API.

Package java.io has about 75 classes and interfaces. Size alone doesn't make an API poor, but there are too many low-value classes (like SequenceInputStream) and it took until JDK 1.5 to get decent support for interactive I/O. Sun got I/O internationalization wrong the first time and had to add many more classes in JDK 1.1 to properly cope with Unicode. The Java I/O package is not intuitive to use, and there are a number of peculiar design choices often reflecting the use of the underlying standard C I/O library. That's the same mistake the Fortran team committed 40 years earlier. Finally, because this library makes heavy use of wrapper classes, you may need to use two or three classes to do simple I/O. Apart from all that, it's really a fine API.

Purpose of java.io package

Enough of the criticism. Obviously, the purpose of the java.io package is to conduct I/O on data and on objects. You will use the java.io package and others to write your data into disk files, into sockets, into URLs, and to the system console, and to read it back again. There is some support for formatting character data, and for processing zip and jar files. Several other packages are involved in this, and the key ones are listed in Table 17-1. The point of presenting this table is to indicate the vast range of Java I/O features.

Table 17-1. Java packages involved with I/O

Package name

Purpose

java.io

Contains the 75 or so classes and interfaces for I/O.

java.nio

New in JDK 1.4. An API for memory-mapped I/O, non-blocking I/O, and file locking.

java.text

For formatting text, dates, numbers, and messages according to national preferences and conventions. This task can now be achieved more easily by using java.util.Formatter in conjunction with PrintWriter.format or printf.

java.util.regex

New in JDK 1.4. For matching a string against a pattern or regular expression.

java.util.zip

Used to read and write zip files.

java.util.logging

New in JDK 1.4. A framework for recording and processing system or application messages to help with later problem diagnosis and resolution.

java.util.jar

Used to read and write jar files.

javax.xml.parsers

New in JDK 1.4. An API to read in and parse XML trees. Covered in Chapter 27.

javax.imageio

New in JDK 1.4. An API for image file I/O (JPEGs, GIFs, etc.) together with common operations for handling them, such as thumbnail processing, conversions between formats, and color model adjustment.

javax.print

New in JDK 1.4. The third attempt at providing a decent enterprise-ready printing service.

javax.comm

Support for accessing serial (RS-232) and parallel (IEEE-1284) port devices. Not part of the basic JDK.

javax.sound.midi

New in JDK 1.3. Provides interfaces and classes for I/O, sequencing, and synthesis of MIDI (Musical Instrument Digital Interface) data.

javax.speech

Speech recognition and output API under development. Third-party implementations are available now. This library will have the biggest impact in Java 2 Micro Edition on telephony applications.

What is a wrapper?

Wrapping an object means accessing its features through some other object, known as the “wrapper.” The wrapper object will augment or improve the features available from the first object. You use the wrapper exclusively, and it in turn will invoke the wrapped object methods as it needs them. Wrapping is widely used in the Java I/O library. In the real world, you might “wrap” a sprinkler with a hosepipe so you get the functionality of water transmission through the hose, with the value-added feature at the end of distributing it in fine drops to irrigate your lawn.

As a programming example, say you had a class that takes ordinary text and prints it out as really nice reports, with page numbers and justified margins, etc. Suppose you also had a second class that translates French text into English text. You could design the translating class so that it “wrapped” the printing class.

The wrapper class would get a stream of French text and translate it into English, as before. Then it would automatically send the results directly on to the wrapped class, where they would be turned into a professional-quality printed document. The net effect would be a couple of classes that worked together to turn French text into nicely printed English documents. You would only need to learn the interface for the wrapper class, since you would invoke all your methods on the wrapper object.

There is even a code idiom for wrapper classes. They are written with a constructor whose argument is the object they will wrap. So, first you instantiate the object that will be wrapped:

NicePrinter iCanPrint = new NicePrinter();

then you instantiate a wrapper object, passing the to-be-wrapped object as an argument.

FrenchToEnglish wrapper = new FrenchToEnglish( iCanPrint );

Behind the scenes, the wrapper object will save a copy of the thing it's wrapping, and you only deal with the wrapper from that point on. When you call a wrapper method, it will do its work and then pass the results on for further processing as appropriate to the wrapped object it saved.

wrapper.setInput("LesMiserables.txt");
wrapper.translateAndPrint();
// automatically sends the translation into the wrapped object
// causing an English translation to get printed nicely.

Clearly, these fictitious FrenchToEnglish and NicePrinter classes have only a loose affinity. The wrapped/wrapper classes in Java I/O are much more tightly coupled. The java.io class that knows how to get data from a file is a “can be wrapped” object. The java.io class that knows how to interpret a data stream as binary values is a “can wrap” object. Put them together, and the wrapper can interpret a stream of binary data from a file. You can layer several wrappers on top of each other. You deal only with the outermost one, but each does its own special value-add and sends the bits on to the next one. Wrapping is a design pattern that is also known as the “Decorator” pattern.

In this chapter we will cover the I/O basics. Chapter 18 covers more advanced I/O topics. By the end of the two I/O chapters, you will be versed in the use of the first five packages listed in Table 17-1. urther Reading on page 423 points out resources for more information on some of the other packages.


[1] See The Cornell Commission on Morris and the worm; T. Eisenberg, D. Gries, J. Hartmanis, D. Holcomb, M. S. Lynn and T. Santoro; Commun. ACM vol. 32, 6 (June 1989), pp. 706–709).

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset
3.144.90.182