Viewing a File Streams

stream. writebyte[] buffer, int startingOffset, int numberOfBytes causes numberOfBytes bytes to be written, starting with the value at buffer[startingOffset] . The fact that the argument to the basic write method is an integer is somewhat peculiar. Recall that read returned an integer, rather than a byte, in order to allow instances of InputStream to signal exceptional conditions. write takes an integer, rather than a byte, so that the read and write method declarations are parallel. In other words, if youve read a value in from a stream, and its not -1, you should be able to write it out to another stream without casting it.

1.1.3.2 Resource management

OutputStream defines two resource management methods: public void close public void flush close serves exactly the same role for OutputStream as it did for InputStream ™itshould be called when the client code is done using the stream and wishes to free up all the associated operating-system resources. The flush method is necessary because output streams frequently use a buffer to store data that is being written. This is especially true when data is being written to either a file or a socket. Passing data to the operating system a single byte at a time can be expensive. A much more practical strategy is to buffer the data at the JVM level and occasionally call flush to send the data en masse.

1.2 Viewing a File

To make this discussion more concrete, we will now discuss a simple application that allows the user to display the contents of a file in a JTextArea . The application is called ViewFile and is shown in Exam ple 1- 1 . Note that the applications main method is defined in the c om.ora.rmibook.chapter1.ViewFile class. [ 3] The resulting screenshot is shown in Figur e 1- 1 . [ 3] This example uses classes from the Java Swing libraries. If you would like more information on Swing, see Java Swing OReilly or Java Foundation Classes in a Nutshell OReilly. Figure 1-1. The ViewFile application Example 1-1. ViewFile.java public class ViewfileFrame extends ExitingFrame{ lots of code to set up the user interface. The View buttons action listener is an inner cl ass private void copyStreamToViewingAreaInputStream fileInputStream throws IOException { BufferedInputStream bufferedStream = new BufferedInputStreamfileInputStream; int nextByte; _fileViewingArea.setText; StringBuffer localBuffer = new StringBuffer ; while -1 = nextByte = bufferedStream.read { char nextChar = char nextByte; localBuffer.appendnextChar; } _fileViewingArea.appendlocalBuffer.toString ; } private class ViewFileAction extends Abs tractAction { public ViewFileAction { putValueAction.NAME, View; putValueAction.SHORT_DESCRIPTION, View file contents in main text area.; } public void actionPerformedActionEvent event { FileInputStream fileInputStream = _fileTextField.getFileInputStream ; if null==fileInputStream { _fileViewingArea.setTextInvalid file name; } else { try { copyStreamToViewingAreafileInputStream; fileInputStream.close ; } catch java.io.IOException ioException { _fileViewingArea.setText\n Error occured while reading file; } } } The important part of the code is the View buttons action listener and the copyStreamToViewingArea method. copyStreamToViewingArea takes an instance of InputStream and copies the contents of the stream to the central JTextArea . What happens when a user clicks on the View button? Assuming all goes well, and that no exceptions are thrown, the following three lines of code from the buttonss action listener are executed: FileInputStream fileInputStream = _fileTextField.getFileInputStream ; copyStreamToViewingAreafileInputStream; fileInputStream.close ; The first line is a call to the getFileInputStream method on _fileTextField . That is, the program reads the name of the file from a text field and tries to open a FileInputStream . FileInputStream is defined in the java.io package. It is a subclass of InputStream used to read the contents of a file. Once this stream is opened, copyStreamToViewingArea is called. copyStream - ToViewingArea takes the input stream, wraps it in a buffer, and then reads it one byte at a time. There are two things to note here: • We explicitly check that nextByte is not equal to -1 e.g., that were not at the end of the file. If we dont do this, the loop will never terminate, and we will we will continue to append char -1 to the end of our text until the program crashes or throws an exception. • We use BufferedInputStream instead of using FileInputStream directly. Internally, a BufferedInputStream maintains a buffer so it can read and store many values at one time. Maintaining this buffer allows instances of Buffered - InputStream to optimize expensive read operations. In particular, rather than reading each byte individually, bufferedStream converts individual calls to its read method into a single call to FileInputStream s readbyte[] buffer method. Note that buffering also provides another benefit. BufferedInputStream supports stream navigation through the use of marking. Of course, the operating system is probably already buffering file reads and writes. But, as we noted above, even the act of passing data to the operating system which uses native methods is expensive and ought to be buffered.

1.3 Layering Streams