CSE 132 (Spring 2009)
Studio 2: Persistence Pays Off

Review studio procedures before starting.

Some guidelines for this week's studio:


  1. Open eclipse and your CSE132 project, or create a new Java project CSE132, asking it to keep source and object files in the same folder (ask a student for help if you need it).
  2. Download and import this zip into your project.


We will first write a tool that reads a file and dumps (prints out) its contents just as it appears in that file. We will use this tool to study how various data types are represented persistently.

  1. Open the Dumpster class that you imported
  2. Notice how the class already imports java.io.*, which contains the classes we need to do I/O.
  3. The String passed to the constructor is the name of the file that should be dumped.
  4. In the constructor, do the following:
    1. Instantiate a new File object based on the String passed to the constructor.
    2. Use that File object to instantiate a new FileInputStream object.
      At this point, eclipse should complain about some unhandled exceptions. Click on the yellow light bulb to see the possible fixes:
      • You can catch the exception here using try...catch.
      • You can propagate the exception back to the caller by adding the throws .... clause to the constructor's declaration.
      Discuss amongst yourselves the tradeoffs in the above approaches, and settle on what your group wants to do. There is no right answer here, but you must be prepared to defend your choice and explain its consequences.
    3. Use that FileInputStream object to instantiate a new DataInputStream object.
      If you decided on the try...catch approach for the previous statement, then you can extend the scope of the try block to include this statement as well.
  5. Look at the objects you instantiated so far and at the documentation of the java.io package (scroll down to the Class Summary).
    What are the responsibilities of the three objects you instantiated above? Explain how the Decorator pattern is used to build increasingly sophisticated input streams.
  6. Make sure that the DataInputStream object is available via an instance variable in your Dumpster class.
  7. Now write a method void dumpNextByte() that:
    1. reads then next byte of the DataInputStream object using its readByte() method.
      • Receive the result of readByte() as a byte variable.
      • You must again figure out what to do with the exceptions that might get thrown from this action. Remember that the goal is just to dump the file, and that end of input will eventually happen.
    2. Prints out the the byte using System.println.
      For now, you can just print out the byte, but you may eventually want to print out the location of the byte in terms of how many bytes have been printed before this one.
      You may also want to see the byte written in a different format as well as the integer format. For example, writing the byte in hex makes it easier to see the bit pattern, since each 4-bit group corresponds to one hexadecimal character.

      Here is a method that converts an int into a String showing its hex representation. A numerical character means what it says. The character A corresponds to 10, B to 11, and so on.

  8. Next write the boolean isDone() method that returns true iff there is no more useful information in the file.
    You should arrange for an instance variable to keep track of whether the file has useful information remaining. The exceptions thrown by the code in dumpNextByte() could set this instance variable to true.
  9. Now test your Dumpster program by running it (as a Java application) on the two files provided:
    It is important at this point to understand why you see what you see. The test.txt file contains ASCII characters, encoded as shown in this table.

    The test.bin file contains a consecutive stream of bytes with values from 0 to 100.

  10. Modify test.txt using the eclipse editor and rerun the Dumpster to experiment with the encoding.
    Don't try to modify the test.bin file: it has binary data in it that cannot easily be edited in eclipse.


We next experiment by writing out some primitive data types to persistent storage, and then using your Dumpster program to examine the results.

  1. Open the Experiment class, and take a look.
    Figure out what the class does, getting help if needed.
  2. Run the Experiment class as a Java application.
    This will write the file exper.bin, which may not show up in your Package view until you refresh the project (function key F5).
    It will also run the Dumpster on the file to show you the output.
    You should see the single byte with value 32.
Now have some fun to answer the following questions. In each case, simply modify the run() method in Experiment to cause things to be written to the exper.bin file.

To write out a primitive type, find the appropriate method (writeByte, writeInt, writeBoolean, etc.) in DataOutputStream.

Don't change your Dumpster code -- let it continue to read the file as a byte stream, so you can see what is inside.

  1. Modify run() so it writes the byte 132 instead of 32. What does your Dumpster show and why?
    Review the two's complement representation if needed.
  2. Try writing 132 using writeInt. What do you see and why?
  3. Try writing the boolean values true and false. What do you see?
  4. If time permits, try writing other things and seeing how they look.

Futher investigation on your own

Consider how Java I/O libraries use the decorator pattern.

That's it for today. Mail the resulting code to members of your group and you'll use this for a simple lab exercise Thursday.

Last modified 20:10:58 CST 11 January 2010 by Ron K. Cytron