16

Files and Streams

Objectives

•To be able to create, read, write and update files.

•To understand the Java streams class hierarchy.

•To be able to use the FileInputStream and

FileOutputStream classes.

•To be able to use the ObjectInputStream and

ObjectOutputStream classes.

•To be able to use class RandomAccessFile.

•To be able to use a JFileChooser dialog to access files and directories.

•To become familiar with sequential-access and random-access file processing.

•To be able to use class File.

I can only assume that a “Do Not File” document is filed in a “Do Not File” file.

Senator Frank Church

Senate Intelligence Subcommittee Hearing, 1975

Consciousness … does not appear to itself chopped up in bits. … A “river” or a “stream” are the metaphors by which it is most naturally described.

William James

I read part of it all the way through.

Samuel Goldwyn

It is quite a three-pipe problem.

Sir Arthur Conan Doyle

impressive functions performed by computers involve only the most fundamental manipulations of 0s and 1s.

The smallest data item in a computer can assume the value 0 or the value 1. Such a data item is called a bit (short for “binary digit”—a digit that can assume one of two values). Computer circuitry performs various simple bit manipulations, such as examining the value of a bit, setting the value of a bit and reversing a bit (from 1 to 0 or from 0 to 1).

It is cumbersome for programmers to work with data in the low-level form of bits. Instead, programmers prefer to work with data in such forms as decimal digits (0–9), letters (A–Z and a–z), and special symbols (e.g., $, @, %, &, *, (, ), -, +, ", :, ?, / and many others). Digits, letters and special symbols are known as characters. The computer’s character set is the set of all characters used to write programs and represent data items. Computers can process only 1s and 0s, so a computer’s character set represents every character as a pattern of 1s and 0s. Characters in Java are Unicode characters composed of 2 bytes. Bytes are most commonly composed of eight bits. Programmers create programs and data items with characters. Computers manipulate and process these characters as patterns of bits. See Appendix K for more information on Unicode.

Just as characters are composed of bits, fields are composed of characters or bytes. A field is a group of characters or bytes that conveys meaning. For example, a field consisting of uppercase and lowercase letters can be used to represent a person’s name.

Data items processed by computers form a data hierarchy in which data items become larger and more complex in structure as we progress from bits, to characters, to fields, etc.

Typically, several fields (called instance variables in Java) compose a record (implemented as a class in Java). In a payroll system, for example, a record for a particular employee might consist of the following fields (possible data types for these fields are shown in parentheses following each field):

•Employee identification number (int)

•Name (String)

•Address (String)

•Hourly pay rate (double)

•Number of exemptions claimed (int)

•Year-to-date earnings (int or double)

•Amount of taxes withheld (int or double)

Thus, a record is a group of related fields. In the preceding example, each of the fields belongs to the same employee. Of course, a particular company might have many employees and will have a payroll record for each employee. A file is a group of related records.1 A company’s payroll file normally contains one record for each employee. Thus, a payroll file for a small company might contain only 22 records, whereas a payroll file for a large company might contain 100,000 records. It is not unusual for a company to have many files, some containing millions, or even billions, of characters of information. Figure 16.1 illustrates the data hierarchy.

1.More generally, a file can contain arbitrary data in arbitrary formats. In some operating systems, a file is viewed as nothing more than a collection of bytes. In such an operating system, any organization of the bytes in a file (such as organizing the data into records) is a view created by the applications programmer.

1Bit

Fig. 16.1 The data hierarchy.

To facilitate the retrieval of specific records from a file, at least one field in each record is chosen as a record key. A record key identifies a record as belonging to a particular person or entity that is unique from all other records. In the payroll record described previously, the employee identification number normally would be chosen as the record key.

There are many ways to organize records in a file. The most common organization is called a sequential file in which records are stored in order by the record-key field. In a payroll file, records are placed in order by employee identification number. The first employee record in the file contains the lowest employee identification number, and subsequent records contain increasingly higher employee identification numbers.

Most businesses store data in many different files. For example, companies might have payroll files, accounts receivable files (listing money due from clients), accounts payable files (listing money due to suppliers), inventory files (listing facts about all the items handled by the business) and many other file types. Often, a group of related files is called a database. A collection of programs designed to create and manage databases is called a database management system (DBMS).

16.3 Files and Streams

Java views each file as a sequential stream of bytes (Fig. 16.2). Each file ends either with an end-of-file marker or at a specific byte number recorded in a system-maintained administrative data structure. Java abstracts this concept from the programmer. A Java program processing a stream of bytes simply receives an indication from the system when the program reaches the end of the stream—the program does not need to know how the underly-

A portion of the class hierarchy of the java.io package

Writer

BufferedWriter

CharArrayWriter

FilterWriter

OutputStreamWriter

FileWriter

PipedWriter

PrintWriter

StringWriter

Fig. 16.3 A portion of the class hierarchy of the java.io package (part 2 of 2).

InputStream and OutputStream (subclasses of Object) are abstract classes that define methods for performing byte-based input and output, respectively.

Programs perform byte-based file input/output with FileInputStream (a subclass of InputStream) and FileOutputStream (a subclass of OutputStream). We use these classes extensively in the examples in this chapter.

Pipes are synchronized communication channels between threads or processes. Java provides PipedOutputStream (a subclass of OutputStream) and PipedInputStream (a subclass of InputStream) to establish pipes between two threads. One thread sends data to another by writing to a PipedOutputStream. The target thread reads information from the pipe via a PipedInputStream.

A PrintStream (a subclass of FilterOutputStream) performs text output to the specified stream. Actually, we have been using PrintStream output throughout the text to this point—System.out is a PrintStream, as is System.err.

A FilterInputStream filters an InputStream, and a FilterOutStream filters an OutputStream; filtering simply means that the filter stream provides additional functionality, such as buffering, monitoring line numbers or aggregating data bytes into meaningful primitive-data-type units. FilterInputStream and FilterOutputStream are abstract classes, so additional functionality is provided by their subclasses.

Reading data as raw bytes is fast but crude. Usually programs read data as aggregates of bytes that form an int, a float, a double and so on. Java programs can use several classes to input and output data in aggregate form.

A RandomAccessFile is useful for direct-access applications, such as transactionprocessing applications like airline-reservations systems and point-of-sale systems. With a sequential-access file, each successive input/output request reads or writes the next consecutive set of data in the file. With a random-access file, each successive input/output request could be directed to any part of the file—perhaps one widely separated from the part of the file referenced in the previous request. Direct-access applications provide rapid access to specific data items in large files; often, such applications are used in applications that require users to wait for answers—these answers must be made available quickly, or the people might become impatient and “take their business elsewhere.”

Chapter 16 Files and Streams 901

The DataInput interface is implemented by class DataInputStream and class RandomAccessFile (discussed later in the chapter); each needs to read primitive data types from a stream. DataInputStreams enable a program to read binary data from an InputStream. The DataInput interface includes methods read (for byte arrays), readBoolean, readByte, readChar, readDouble, readFloat, readFully (for byte arrays), readInt, readLong, readShort, readUnsignedByte, readUnsignedShort, readUTF (for strings) and skipBytes.

The DataOutput interface is implemented by class DataOutputStream (a subclass of FilterOutputStream) and class RandomAccessFile; each needs to write primitive data types to an OutputStream. DataOutputStreams enable a program to write binary data to an OutputStream. The DataOutput interface includes methods flush, size, write (for a byte), write (for a byte array), writeBoolean, writeByte, writeBytes, writeChar, writeChars (for Unicode Strings), writeDouble, writeFloat, writeInt, writeLong, writeShort and writeUTF.

Buffering is an I/O-performance-enhancement technique. With a BufferedOutputStream (a subclass of class FilterOutputStream), each output statement does not necessarily result in an actual physical transfer of data to the output device. Rather, each output operation is directed to a region in memory called a buffer that is large enough to hold the data of many output operations. Then, actual transfer to the output device is performed in one large physical output operation each time the buffer fills. The output operations directed to the output buffer in memory are often called logical output operations. With a BufferedOutputStream, a partially filled buffer can be forced out to the device at any time by invoking the stream object’s flush method.

Performance Tip 16.1

Since typical physical output operations are extremely slow compared to the speed of access- ing computer memory, buffered outputs normally yield significant performance improvements over unbuffered outputs.

With a BufferedInputStream (a subclass of class FilterInputStream), many “logical” chunks of data from a file are read as one large physical input operation into a memory buffer. As a program requests each new chunk of data, it is taken from the buffer (this is sometimes referred to as a logical input operation). When the buffer is empty, the next actual physical input operation from the input device is performed to read in the next group of “logical” chunks of data. Thus, the number of actual physical input operations is small compared with the number of read requests issued by the program.

Performance Tip 16.2

Since typical input operations are extremely slow compared to the speed of accessing com- puter memory, buffered inputs normally yield significant performance improvements over unbuffered inputs.

A PushbackInputStream (a subclass of class FilterInputStream) is for applications more exotic than those most programmers require. Essentially, the application reading a PushbackInputStream reads bytes from the stream and forms aggregates consisting of several bytes. Sometimes, to determine that one aggregate is complete, the application must read the first character “past the end” of the first aggregate. Once the program determines that the current aggregate is complete, the extra character is “pushed

back” onto the stream. PushbackInputStreams are used by programs (like compilers) that parse their inputs—that is, break them into meaningful units (such as the keywords, identifiers and operators that the compiler must recognize).

When object instance variables are output to a disk file, in a sense we lose the object’s type information. We have only data, not type information, on a disk. If the program that is going to read this data knows what object type it corresponds to, then the data is simply read into objects of that type. Sometimes, we would like to read or write an entire object to a file. The ObjectInputStream and ObjectOutputStream classes, which respectively implement the ObjectInput and ObjectOutput interfaces, enable an entire object to be read from or written to a file (or other stream type). We often chain ObjectInputStreams to FileInputStreams. (We also chain ObjectOutputStreams to FileOutputStreams.) The ObjectOutput interface contains method writeObject, which takes an Object that implements interface Serializable as an argument and writes its information to the OutputStream. Correspondingly, the ObjectInput interface requires method readObject, which reads and returns an Object from an InputStream. After the reading of an object, it can be cast to the desired type. Additionally, these interfaces include other Object-centric methods as well as the same methods as DataInput and DataOutput for reading and writing primitive data types.

Java stream I/O includes capabilities for inputting from byte arrays in memory and outputting to byte arrays in memory. A ByteArrayInputStream (a subclass of

InputStream) reads from a byte array in memory. A ByteArrayOutputStream

(a subclass of OutputStream) outputs to a byte array in memory. One application of byte-array I/O is data validation. A program can input an entire line at a time from the input stream into a byte array. Then, a validation routine can scrutinize the contents of the byte array and correct the data, if necessary. Then, the program can proceed to input from the byte array, knowing that the input data is in the proper format. Outputting to a byte array is a nice way to take advantage of the powerful output-formatting capabilities of Java streams. For example, data can be prepared in a byte array, using the same formatting that will be displayed at a later time, then output to a disk file to preserve the screen image.

A SequenceInputStream (a subclass of InputStream) enables concatenation of several InputStreams, so that the program sees the group as one continuous InputStream. As the program reaches the end of an input stream, that stream closes and the next stream in the sequence opens.

In addition to the byte based streams, Java provides Reader and Writer classes, which are Unicode, two-byte, character based streams. Most of the byte-based streams have corresponding character-based Reader or Writer classes.

Class BufferedReader (a subclass of abstract class Reader) and class BufferedWriter (a subclass of abstract class Writer) enable efficient buffering for character-based streams. Character-based streams use Unicode characters—such streams can process data in any language that the Unicode character set represents.

Class CharArrayReader and class CharArrayWriter read and write a stream of characters to a character array.

A PushbackReader (a subclass of abstract class FilterReader) enables characters to be pushed back on a character stream. A LineNumberReader (a subclass of BufferedReader) is a buffered character-stream that keeps track of line numbers (i.e., a newline, a return or a carriage-return line-feed combination).

Class FileReader (a subclass of InputStreamReader) and class FileWriter (a subclass of OutputStreamWriter) read characters from and write characters to a file, respectively. Class PipedReader and class PipedWriter implement piped-character streams that can be used to transfer information between threads. Class StringReader and StringWriter read and write characters to Strings. A PrintWriter writes characters to a stream.

Class File enables programs to obtain information about a file or directory. We discuss class File extensively in Section 16.12.

16.4 Creating a Sequential-Access File

Java imposes no structure on a file. Notions like “record” do not exist in Java files. Therefore, the programmer must structure files to meet the requirements of applications. In the following example, we see how the programmer can impose a simple record structure on a file. First we present the program, then we analyze it in detail.

The program of Fig. 16.4–Fig. 16.6 creates a simple sequential-access file that might be used in an accounts receivable system to help manage the money owed by a company’s credit clients. For each client, the program obtains an account number, the client’s first name, the client’s last name and the client’s balance (i.e., the amount the client still owes the company for goods and services received in the past). The data obtained for each client constitutes a record for that client. The program uses the account number as the record key; that is, the file will be created and maintained in account-number order. [Note: This program assumes the user enters the records in account-number order. In a comprehensive accounts receivable system, a sorting capability would be provided so the user could enter the records in any order—the records would then be sorted and written to the file.]

Most of the programs in this chapter have a similar GUI, so this program defines class BankUI (Fig. 16.4) to encapsulate the GUI. (See the second sample output screen in Fig. 16.6.) Also, the program defines class AccountRecord (Fig. 16.5) to encapsulate the client record information (i.e., account, first name, etc.) used by the examples in this chapter. For reuse, classes BankUI and AccountRecord are defined in package com.deitel.jhtp4.ch16.

[Note: Most of the programs in this chapter use classes BankUI and AccountRecord. When you compile these classes, or any others that will be reused in this chapter, you should place the classes in a common directory. When you compile classes that use BankUI and AccountRecord, be sure to specify the -classpath command line argument to both javac and java, as in

javac -classpath .;packageLocation ClassName.java java -classpath .;packageLocation ClassName

where packageLocation represents the common directory in which the classes of the package com.deitel.jhtp4.ch16 reside and ClassName represents the class to compile or execute. Be sure to include the current directory (specified with .) in the class path. [Note: If your packaged classes are in a JAR file, the packageLocation should include the location and name of the actual JAR file.] Also, the path separator shown (;, which is used in Microsoft Windows) should be appropriate for your platform (such as : on UNIX/Linux).]

Class BankUI (Fig. 16.4) contains two JButtons and arrays of JLabels and JTextFields. The number of JLabels and JTextFields is set with the constructor

defined at lines 34–75. Methods getFieldValues (lines 116–124), setFieldValues (lines 104–113) and clearFields (lines 96–100) manipulate the text of the

JTextFields. Methods getFields (lines 90–93), getDoTask1Button (lines 78– 81) and getDoTask2Button (lines 84–87) return individual GUI components, so that a client program can add ActionListeners (for example).

1// Fig. 16.4: BankUI.java

2 // A reusable GUI for the examples in this chapter. 3 package com.deitel.jhtp4.ch16;

4

5 // Java core packages

6 import java.awt.*;

7

8 // Java extension packages

9 import javax.swing.*;

10

11 public class BankUI extends JPanel {

12

13// label text for GUI

14protected final static String names[] = { "Account number",

15"First name", "Last name", "Balance",

16"Transaction Amount" };

17

18// GUI components; protected for future subclass access

19protected JLabel labels[];

20protected JTextField fields[];

21protected JButton doTask1, doTask2;

22protected JPanel innerPanelCenter, innerPanelSouth;

23

24// number of text fields in GUI

25protected int size;

26

27// constants representing text fields in GUI

28public static final int ACCOUNT = 0, FIRSTNAME = 1,

29LASTNAME = 2, BALANCE = 3, TRANSACTION = 4;

30

31// Set up GUI. Constructor argument of 4 creates four rows

32// of GUI components. Constructor argument of 5 (used in a

33// later program) creates five rows of GUI components.

34public BankUI( int mySize )

35{

36size = mySize;

37labels = new JLabel[ size ];

38fields = new JTextField[ size ];

39

40// create labels

41for ( int count = 0; count < labels.length; count++ )

44// create text fields

45for ( int count = 0; count < fields.length; count++ )

Fig. 16.4 BankUI contains a reusable GUI for several programs (part 1 of 3).

47

48// create panel to lay out labels and fields

49innerPanelCenter = new JPanel();

50innerPanelCenter.setLayout( new GridLayout( size, 2 ) );

52// attach labels and fields to innerPanelCenter

53for ( int count = 0; count < size; count++ ) {

55innerPanelCenter.add( fields[ count ] );

56}

57

58// create generic buttons; no labels or event handlers

59doTask1 = new JButton();

60doTask2 = new JButton();

61

62// create panel to lay out buttons and attach buttons

63innerPanelSouth = new JPanel();

64innerPanelSouth.add( doTask1 );

65innerPanelSouth.add( doTask2 );

66

67// set layout of this container and attach panels to it

68setLayout( new BorderLayout() );

69add( innerPanelCenter, BorderLayout.CENTER );

70add( innerPanelSouth, BorderLayout.SOUTH );

71

72// validate layout

73validate();

74

75 } // end constructor

76

77// return reference to generic task button doTask1

78public JButton getDoTask1Button()

79{

80return doTask1;

81}

82

83// return reference to generic task button doTask2

84public JButton getDoTask2Button()

85{

86return doTask2;

87}

88

89// return reference to fields array of JTextFields

90public JTextField[] getFields()

91{

92return fields;

93}

94

95// clear content of text fields

96public void clearFields()

97{

98for ( int count = 0; count < size; count++ )

Fig. 16.4 BankUI contains a reusable GUI for several programs (part 2 of 3).

102// set text field values; throw IllegalArgumentException if

103// incorrect number of Strings in argument

104public void setFieldValues( String strings[] )

105throws IllegalArgumentException

106{

107if ( strings.length != size )

108throw new IllegalArgumentException( "There must be " +

111for ( int count = 0; count < size; count++ )

112fields[ count ].setText( strings[ count ] );

113}

114

115// get array of Strings with current text field contents

116public String[] getFieldValues()

117{

118String values[] = new String[ size ];

119

120for ( int count = 0; count < size; count++ )

121values[ count ] = fields[ count ].getText();

123return values;

124}

125

126 } // end class BankUI

Fig. 16.4 BankUI contains a reusable GUI for several programs (part 3 of 3).

Class AccountRecord (Fig. 16.5) implements interface Serializable, which allows objects of AccountRecord to be used with ObjectInputStreams and

ObjectOutputStreams. Interface Serializable is known as a tagging interface. Such an interface contains no methods. A class that implements this interface is tagged as being a Serializable object, which is important because an ObjectOutputStream will not output an object unless it is a Serializable object. In a class that implements Serializable, the programmer must ensure that every instance variable of the class is a Serializable type, or must declare particular instance variables as transient to indicate that those variables are not Serializable and they should be ignored during the serialization process. By default, all primitive type variables are transient. For non-primitive types, you must check the definition of the class (and possibly its superclasses) to ensure that the type is Serializable. Class AccountRecord contains private data members account, firstName, lastName and balance. This class also provides public “get” and “set” methods for accessing the private data members.

1// Fig. 16.5: AccountRecord.java

2 // A class that represents one record of information.

3package com.deitel.jhtp4.ch16;

Fig. 16.5 Class AccountRecord maintains information for one account (part 1 of 3).

55// set last name

56public void setLastName( String last )

57{

58lastName = last;

59}

60

61// get last name

62public String getLastName()

63{

64return lastName;

65}

66

67// set balance

68public void setBalance( double bal )

69{

70balance = bal;

71}

72

73// get balance

74public double getBalance()

75{

76return balance;

77}

78

79 } // end class AccountRecord

Fig. 16.5 Class AccountRecord maintains information for one account (part 3 of 3).

Now, let us discuss the code that creates the sequential-access file (Fig. 16.6). In this example, we introduce class JFileChooser (package javax.swing) for selecting files (as on the second screen in Fig. 16.6). Line 103 constructs a JFileChooser instance and assigns it to reference fileChooser. Lines 104–105 call method setFileSelectionMode to specify what the user can select from the fileChooser. For this program, we use JFileChooser static constant FILES_ONLY to indicate that only files can be selected. Other static constants include FILES_AND_DIRECTORIES and

DIRECTORIES_ONLY.

1// Fig. 16.6: CreateSequentialFile.java

2 // Demonstrating object output with class ObjectOutputStream. 3 // The objects are written sequentially to a file.

4

5 // Java core packages

6 import java.io.*;

7import java.awt.*;

8 import java.awt.event.*;

9

10// Java extension packages

11import javax.swing.*;

12

Fig. 16.6 Creating a sequential file (part 1 of 6).

Select location for file here

Click Save to submit new

file name to program

Files and directories are displayed here

BankUI graphical user interface

Fig. 16.6 Creating a sequential file (part 6 of 6).

Line 107 calls method showSaveDialog to display the JFileChooser dialog titled Save. Argument this specifies the JFileChooser dialog’s parent window, which determines the position of the dialog on the screen. If null is passed, the dialog is displayed in the center of the window; otherwise, the dialog is centered over the application window. When displayed, a JFileChooser dialog does not allow the user to interact with any other program window until the user closes the JFileChooser dialog by clicking Save or Cancel. Dialogs that behave in this fashion are called modal dialogs. The user selects the drive, directory and file name, then clicks Save. Method showSaveDialog returns an integer specifying which button the user clicked (Save or Cancel) to close the dialog. Line 110 tests whether the user clicked Cancel by comparing result to static constant CANCEL_OPTION. If so, the method returns.

70// get reference to generic task button doTask2 from BankUI

71nextButton = userInterface.getDoTask2Button();

72nextButton.setText( "Next Record" );

73nextButton.setEnabled( false );

74

75// register listener to call readRecord when button pressed

76nextButton.addActionListener(

91pack();

92setSize( 300, 200 );

93show();

94

95 } // end ReadSequentialFile constructor

96

97// enable user to select file to open

98private void openFile()

99{

100// display file dialog so user can select file to open

101JFileChooser fileChooser = new JFileChooser();

102fileChooser.setFileSelectionMode(

103JFileChooser.FILES_ONLY );

104

105 int result = fileChooser.showOpenDialog( this );

106

107// if user clicked Cancel button on dialog, return

108if ( result == JFileChooser.CANCEL_OPTION )

109return;

110

111// obtain selected file

112File fileName = fileChooser.getSelectedFile();

114// display error if file name invalid

115if ( fileName == null ||

116fileName.getName().equals( "" ) )

117JOptionPane.showMessageDialog( this,

Fig. 16.8 Reading a sequential file (part 3 of 6).

Fig. 16.8 Reading a sequential file (part 6 of 6).

Most of the code in this example is similar to Fig. 16.6, so we discuss only the key lines of code that are different. Line 105 calls JFileChooser method showOpenDialog to display the Open dialog (second screen capture in Fig. 16.8). The behavior and GUI are the same as the dialog displayed by showSaveDialog, except that the title of the dialog and the Save button are both replaced with Open.

Lines 125–126 create a ObjectInputStream object and assign it to input. The File fileName is passed to the FileInputStream constructor to open the file.

The program reads a record from the file each time the user clicks the Next Record button. Line 84 in Next Record’s actionPerformed method calls method readRecord (lines 144–187) to read one record from the file. Line 150 calls method readObject to read an Object from the ObjectInputStream. To use AccountRecord specific methods, we cast the returned Object to type AccountRecord. If the end-of-file marker is reached during reading, readObject throws an EndOfFileException.

To retrieve data sequentially from a file, programs normally start reading from the beginning of the file and read all the data consecutively until the desired data are found. It might be necessary to process the file sequentially several times (from the beginning of the file) during the execution of a program. Class FileInputStream does not provide the ability to reposition to the beginning of the file to read the file again unless the program closes the file and reopens it. Class RandomAccessFile objects can reposition to the beginning of the file. Class RandomAccessFile provides all the capabilities of the

classes FileInputStream, FileOutputStream, DataInputStream and

DataOutputStream and adds several other methods, including a seek that repositions the file-position pointer (the byte number of the next byte in the file to be read or written) to any position in the file. However, class RandomAccessFile cannot read and write entire objects.

Performance Tip 16.5

The process of closing and reopening a file for the purpose of positioning the file-position pointer back to the beginning of a file is a time-consuming task for the computer. If this is done frequently, it can slow the performance of your program.

The program of Fig. 16.9 enables a credit manager to display the account information for those customers with zero balances (i.e., customers who do not owe the company any money), credit balances (i.e., customers to whom the company owes money) and debit balances (i.e., customers who owe the company money for goods and services received in the past).

The program displays buttons that allow a credit manager to obtain credit information. The Credit balances button produces a list of accounts with credit balances. The Debit balances button produces a list of accounts with debit balances. The Zero balances button produces a list of accounts with zero balances.

Records are displayed in a JTextArea called recordDisplayArea. The record information is collected by reading through the entire file and determining, for each record, whether it satisfies the criteria for the account type selected by the credit manager. Clicking one of the balance buttons sets variable accountType (line 274) to the clicked button’s text (e.g., Zero balances) and invokes method readRecords (191–238), which loops through the file and reads every record. Line 208 of method readRecords calls method shouldDisplay (241–259) to determine whether the current record satisfies the account type requested. If shouldDisplay returns true, the program appends the account information for the current record to the JTextArea recordDisplay. When the end- of-file marker is reached, line 219 calls method closeFile to close the file.

1// Fig. 16.9: CreditInquiry.java

2 // This program reads a file sequentially and displays the 3 // contents in a text area based on the type of account the 4 // user requests (credit balance, debit balance or

5 // zero balance).

6

7 // Java core packages

8 import java.io.*;

9import java.awt.*;

10import java.awt.event.*;

11import java.text.DecimalFormat;

13// Java extension packages

14import javax.swing.*;

15

16// Deitel packages

17import com.deitel.jhtp4.ch16.AccountRecord;

Fig. 16.9 Credit inquiry program (part 1 of 7).

129// if user clicked Cancel button on dialog, return

130if ( result == JFileChooser.CANCEL_OPTION )

133// obtain selected file

134fileName = fileChooser.getSelectedFile();

135}

136

137// display error if file name invalid

138if ( fileName == null ||

139fileName.getName().equals( "" ) )

140JOptionPane.showMessageDialog( this,

146// open file

147try {

158zeroButton.setEnabled( true );

159}

160

161// catch problems manipulating file

162catch ( IOException ioException ) {

166}

167}

169 } // end method openFile

170

171// close file before application terminates

172private void closeFile()

173{

174// close file

175try {

176input.close();

Fig. 16.9 Credit inquiry program (part 4 of 7).

179// process exception from closing file

180catch ( IOException ioException ) {

181JOptionPane.showMessageDialog( this,

185System.exit( 1 );

186}

187}

188

189// read records from file and display only records of

190// appropriate type

191private void readRecords()

192{

193AccountRecord record;

194DecimalFormat twoDigits = new DecimalFormat( "0.00" );

195openFile( false );

196

197// read records

198try {

199recordDisplayArea.setText( "The accounts are:\n" );

201// input the values from the file

202while ( true ) {

214}

215}

217// close file when end-of-file reached

218catch ( EOFException eofException ) {

219closeFile();

220}

221

222// display error if cannot read object

223// because class not found

224catch ( ClassNotFoundException classNotFound ) {

225JOptionPane.showMessageDialog( this,

227"Class Not Found", JOptionPane.ERROR_MESSAGE );

228}

229

Fig. 16.9 Credit inquiry program (part 5 of 7).

Fig. 16.9 Credit inquiry program (part 7 of 7).

16.6 Updating Sequential-Access Files

Data that is formatted and written to a sequential-access file as shown in Section 16.4 cannot be modified without reading and writing all the data in the file. For example, if the name White needed to be changed to Worthington, the old name cannot simply be overwritten. Such updating can be done, but it is awkward. To make the preceding name change, the records before White in a sequential-access file could be copied to a new file, the updated record would then be written to the new file, and the records after White would be copied to the new file. This requires processing every record in the file to update one record. If many records are being updated in one pass of the file, this technique can be acceptable.

16.7 Random-Access Files

So far, we have seen how to create sequential-access files and to search through them to locate particular information. Sequential-access files are inappropriate for so-called “in- stant-access” applications, in which a particular record of information must be located immediately. Some popular instant-access applications are airline reservation systems, banking systems, point-of-sale systems, automated-teller machines and other kinds of transaction-processing systems that require rapid access to specific data. The bank at which you have your account might have hundreds of thousands or even millions of other customers, yet, when you use an automated teller machine, the bank determines in seconds whether your account has sufficient funds for the transaction. This kind of instant access is possible with random-access files. A program can access individual records of a randomaccess file directly (and quickly) without searching through other records. Random-access files are sometimes called direct-access files.

As we have said, Java does not impose structure on a file, so an application that wants to use random-access files must create them. Several techniques can be used to create random-access files. Perhaps the simplest is to require that all records in a file be of the same fixed length.

Using fixed-length records makes it easy for a program to calculate (as a function of the record size and the record key) the exact location of any record relative to the beginning of the file. We will soon see how this facilitates immediate access to specific records, even in large files.

Figure 16.10 illustrates Java’s view of a random-access file composed of fixed-length records (each record in this figure is 100 bytes long). A random-access file is like a railroad train with many cars—some empty, some with contents.

A program can insert data in a random-access file without destroying other data in the file. Also, a program can update or delete data stored previously without rewriting the entire file. In the following sections, we explain how to create a random-access file, enter data, read the data both sequentially and randomly, update the data and delete data no longer needed.

16.8 Creating a Random-Access File

RandomAccessFile objects have all the capabilities of DataInputStream and DataOutputStream objects discussed earlier. When a program associates an object of class RandomAccessFile with a file, the program reads or writes data beginning at the location in the file specified by the file-position pointer and manipulates all data as primitive data types. When writing an int value, 4 bytes are output to the file. When reading a double value, 8 bytes are input from the file. The size of the data types is guaranteed, because Java has fixed sizes for all primitive data types regardless of the computing platform.

Random-access file-processing programs rarely write a single field to a file. Normally, they write one object at a time, as we show in the following examples.

Consider the following problem statement:

Create a transaction-processing program capable of storing up to 100 fixed-length records for a company that can have up to 100 customers. Each record should consist of an account number that will be used as the record key, a last name, a first name and a balance. The program should be able to update an account, insert a new account and delete an account.

byte offsets

Fig. 16.10 Java’s view of a random-access file.

The next several sections introduce the techniques necessary to create this credit-pro- cessing program. Figure 16.11 contains the RandomAccessAccountRecord class that is used by the next four programs for both reading records from and writing records to a file.

1// Fig. 16.11: RandomAccessAccountRecord.java

2 // Subclass of AccountRecord for random access file programs. 3 package com.deitel.jhtp4.ch16;

4

5 // Java core packages

6 import java.io.*;

7

8 public class RandomAccessAccountRecord extends AccountRecord {

9

10// no-argument constructor calls other constructor

11// with default values

12public RandomAccessAccountRecord()

13{

14this( 0, "", "", 0.0 );

15}

16

17// initialize a RandomAccessAccountRecord

18public RandomAccessAccountRecord( int account,

19String firstName, String lastName, double balance )

20{

21super( account, firstName, lastName, balance );

22}

23

24// read a record from specified RandomAccessFile

25public void read( RandomAccessFile file ) throws IOException

26{

27setAccount( file.readInt() );

28setFirstName( padName( file ) );

29setLastName( padName( file ) );

30setBalance( file.readDouble() );

31}

32

Fig. 16.11 RandomAccessAccountRecord class used in the random-access file programs (part 1 of 2).

33// ensure that name is proper length

34private String padName( RandomAccessFile file )

35throws IOException

36{

37char name[] = new char[ 15 ], temp;

41name[ count ] = temp;

42}

43

44return new String( name ).replace( '\0', ' ' );

45}

46

47// write a record to specified RandomAccessFile

48public void write( RandomAccessFile file ) throws IOException

49{

50file.writeInt( getAccount() );

51writeName( file, getFirstName() );

52writeName( file, getLastName() );

53file.writeDouble( getBalance() );

54}

55

56// write a name to file; maximum of 15 characters

57private void writeName( RandomAccessFile file, String name )

58throws IOException

59{

60StringBuffer buffer = null;

61

62 if ( name != null )

63buffer = new StringBuffer( name );

64else

67buffer.setLength( 15 );

68file.writeChars( buffer.toString() );

69}

70

71// NOTE: This method contains a hard coded value for the

72// size of a record of information.

73public static int size()

74{

75return 72;

76}

77

78 } // end class RandomAccessAccountRecord

Fig. 16.11 RandomAccessAccountRecord class used in the random-access file programs (part 2 of 2).

Class RandomAccessAccountRecord inherits AccountRecord’s (Fig. 16.5) implementation, which includes private instance variables—account, lastName, firstName and balance—as well as their public set and get methods.

Method read (lines 25–31) reads one record from the RandomAccessFile object passed as an argument. Methods readInt (line 27) and readDouble (line 30) read the account and balance, respectively. Method read calls private method padName (lines 34–45) twice to obtain the first and last names. Method padName reads fifteen characters from the RandomAccessFile and returns a String. If a name is shorter than 15 characters, the program fills each extra character with a null byte ('\0'). Swing components, such as JTextFields, cannot display null byte characters (which are displayed instead as rectangles). Line 44 solves this problem by replacing null bytes with spaces.

Method write (48–54) outputs one record to the RandomAccessFile object passed in as an argument. This method uses method writeInt to output the integer account, method writeChars (called from utility method writeName) to output the firstName and lastName character arrays and method writeDouble to output the double balance. [Note: In order to ensure that all records in the RandomAccessFile have the same size, we write exactly 15 characters for the first name and exactly 15 characters for the last name.] Method writeName (lines 57–69) performs the write operations for the first and last name.

Figure 16.12 illustrates opening a random-access file and writing data to the disk. This program writes 100 RandomAccessAccountRecords, using method write (Fig. 16.11). Each RandomAccessAccountRecord object contains 0 for the account number, null for the last name, null for the first name and 0.0 for the balance. The file is initialized to create the proper amount of “empty” space in which the account data will be stored and to enable us to determine in subsequent programs whether each record is empty or contains data.

1// Fig. 16.12: CreateRandomFile.java

2 // This program creates a random access file sequentially 3 // by writing 100 empty records to disk.

4

5 // Java core packages

6 import java.io.*;

7

8 // Java extension packages

9 import javax.swing.*;

10

11// Deitel packages

12import com.deitel.jhtp4.ch16.RandomAccessAccountRecord;

14 public class CreateRandomFile {

15

16// enable user to select file to open

17private void createFile()

18{

19// display dialog so user can choose file

20JFileChooser fileChooser = new JFileChooser();

21fileChooser.setFileSelectionMode(

25

26// if user clicked Cancel button on dialog, return

27if ( result == JFileChooser.CANCEL_OPTION )

30// obtain selected file

31File fileName = fileChooser.getSelectedFile();

33// display error if file name invalid

34if ( fileName == null ||

73}

74}

75

76 } // end method openFile

77

Fig. 16.12 Creating a random-access file sequentially (part 2 of 3).

78// execute application to create file user specifies

79public static void main( String args[] )

80{

81CreateRandomFile application = new CreateRandomFile();

83application.createFile();

84}

85

86 } // end class CreateRandomFile

Fig. 16.12 Creating a random-access file sequentially (part 3 of 3).

Lines 44–45 attempt to open a RandomAccessFile for use in this program. The RandomAccessFile constructor receives two arguments—the file name and the file open mode. The file open mode for a RandomAccessFile is either "r" to open the file for reading or "rw" to open the file for reading and writing.

If an IOException occurs during the open process, the program displays a message dialog and terminates. If the file opens properly, the program uses a for structure (lines 51–52) to invoke RandomAccessAccountRecord method write 100 times. This statement causes the data members of object blankRecord to be written to the file associated with RandomAccessFile object file.

16.9 Writing Data Randomly to a Random-Access File

Figure 16.13 writes data to a file that is opened with the "rw" mode for reading and writing. It uses the RandomAccessFile method seek to determine the exact location in the file at which a record of information is stored. Method seek sets the file-position pointer to a specific position in the file relative to the beginning of the file, and the RandomAccessAccountRecord class method write outputs the data. This program assumes

the user does not enter duplicate account numbers and that the user enters appropriate data in each JTextField.

1// Fig. 16.13: WriteRandomFile.java

2 // This program uses textfields to get information from the 3 // user at the keyboard and writes the information to a

4 // random-access file.

5

6 // Java core packages

7import java.awt.*;

8 import java.awt.event.*;

9 import java.io.*;

10

11// Java extension packages

12import javax.swing.*;

13

14// Deitel packages

15import com.deitel.jhtp4.ch16.*;

17public class WriteRandomFile extends JFrame {

18private RandomAccessFile output;

19private BankUI userInterface;

20private JButton enterButton, openButton;

22// set up GUI

23public WriteRandomFile()

24{

25super( "Write to random access file" );

27// create instance of reusable user interface BankUI

28userInterface = new BankUI( 4 ); // four textfields

29getContentPane().add( userInterface,

32// get reference to generic task button doTask1 in BankUI

33openButton = userInterface.getDoTask1Button();

34openButton.setText( "Open..." );

35

36// register listener to call openFile when button pressed

37openButton.addActionListener(

51

52// register window listener for window closing event

53addWindowListener(

71// get reference to generic task button doTask2 in BankUI

72enterButton = userInterface.getDoTask2Button();

73enterButton.setText( "Enter" );

74enterButton.setEnabled( false );

75

76// register listener to call addRecord when button pressed

77enterButton.addActionListener(

92setSize( 300, 150 );

93show();

94}

95

96// enable user to choose file to open

97private void openFile()

98{

99// display file dialog so user can select file 100 JFileChooser fileChooser = new JFileChooser();

101fileChooser.setFileSelectionMode(

102JFileChooser.FILES_ONLY );

103

Fig. 16.13 Writing data randomly to a random-access file (part 2 of 5).

104 int result = fileChooser.showOpenDialog( this );

105

106// if user clicked Cancel button on dialog, return

107if ( result == JFileChooser.CANCEL_OPTION )

108return;

109

110// obtain selected file

111File fileName = fileChooser.getSelectedFile();

113// display error if file name invalid

114if ( fileName == null ||

115fileName.getName().equals( "" ) )

116JOptionPane.showMessageDialog( this,

122// open file

123try {

126openButton.setEnabled( false );

127}

128

129// process exception while opening file

130catch ( IOException ioException ) {

135}

136}

138 } // end method openFile

139

140// close file and terminate application

141private void closeFile()

142{

143// close file and exit

144try {

145if ( output != null )

148System.exit( 0 );

149}

150

151// process exception while closing file

152catch( IOException ioException ) {

153JOptionPane.showMessageDialog( this,

209// execute application

210public static void main( String args[] )

211{

212new WriteRandomFile();

213}

214

215 } // end class WriteRandomFile

Fig. 16.13 Writing data randomly to a random-access file (part 5 of 5).

The user enters values for the account number, first name, last name and balance. When the user clicks the Enter button, the program calls method addRecord (162–207) of class WriteRandomFile to retrieve the data from the BankAccountUI’s JTextFields, store the data in RandomAccessAccountRecord class object record and call the write method of class RandomAccessAccountRecord to output the data.

Lines 185–186 call RandomAccessFile method seek to position the file-position pointer for object output to the byte location calculated by ( accountNumber - 1 ) * RandomAccessAccountRecord.size(). Account numbers in this program should be between 1 and 100. We subtract 1 from the account number when calculating the byte location of the record. Thus, for record 1, the file-position pointer is set to byte 0 of the file.

35// register listener to call openFile when button pressed

36openButton.addActionListener(

51// configure generic doTask2 button from BankUI

52nextButton = userInterface.getDoTask2Button();

53nextButton.setText( "Next" );

54nextButton.setEnabled( false );

55

56// register listener to call readRecord when button pressed

57nextButton.addActionListener(

72// register listener for window closing event

73addWindowListener(