CS 117: Files, mice, and keys
Winter 2005

In this lab, you will experiment with existing Java programs with the goal of learning how to use files, mouse clicks, and keystrokes in your programs.

Files

Suppose you have a file called words.txt that consists of one word per line, and you want to sort the words. An array or an ArrayList plus insertion sort can handle the computational job, but how do you get the words out of words.txt in the first place, and where should the results go when you're done? In this part of the lab, we're going to experiment with several approaches to this question.

Standard input and standard output

The Java object System.in is an object of type InputStream that is initialized for you whenever you run a Java program. Normally, System.in is set up to take input from the keyboard, but in most command-line systems, there's a way to cause System.in to take input from a file, instead. Similarly, System.out, an object of type PrintStream, is normally initialized to send output to the screen, but can be "redirected" to a file via the command line. Almost all programming languages provide you with a way to read from "standard input" and write to "standard output"; System.in and System.out are Java's way. In this section of the lab, you will run a sorting program in several ways to see how standard input and standard output work.

Redirecting standard input

Make yourself a working directory and copy all the files for today's lab to it. (The command "cp /Accounts/courses/cs117/ondich/fileslab/* ." should do the job.) We'll start work with WordSorter1.java.

Open WordSorter1.java and take a look at it. It uses an ArrayList to store the words, and insertion sort in the sort method. But take a look at the constructor, where we load the words from the file into the ArrayList. Note that we are using a Scanner based on System.in, which we normally use for the keyboard.

Now try the following.

• Create a file called words.txt consisting of one word per line. Don't put the words in alphabetical order.
• Compile WordSorter1.java.
• Run the command "java WordSorter1 < words.txt". What happened?
• Run the command "java WordSorter1". What happened? Why? (You may now use Ctrl-C to stop the program, if you wish.)

The moral? You can "redirect" standard input to a file using the < character on the command line.

Not redirecting standard input

There's a handy technique that's a lot less common than redirecting standard input, if you want to test a program on a "file" that doesn't exist. Try the following.

• Run the command "java WordSorter1".
• As before, this command hangs, waiting for input to arrive. To provide input, just type a few words, one per line. Once you've typed enough words to satisfy yourself, hit Enter to get to the beginning of a line and then type Ctrl-D. This will signal the command-line system that the input is complete. What happens?

Redirecting standard output

Now, let's send the output of WordSorter1.java to a file via redirection.

• Run the command "java WordSorter1 < words.txt > output.txt".
• Does the file output.txt exist now? What's in it?
• Try "java WordSorter1 > output.txt", with typed input with a Ctrl-D at the end. Does the expected output make its way to output.txt?

Using File objects for input and output

In many programs, it's not reasonable for all the input to come from a single file, nor for all the output to go to a single file. Think of a spell-checker, for example, which needs to take input from both a dictionary file and the file whose spelling you want checked. In such cases, you can't depend on command-line redirection.

Let's give it a try.

• Take a look at WordSorter2.java. How does it differ from WordSorter1.java? Compile it and run it with no command-line arguments. Where does the output go? Is it the expected output?
• Take a look at WordSorter3.java. Try it out and see whether it works as you expect it to.
• Modify WordSorter3.java to allow the user to specify the input and output files on the command line, like so: "java WordSorter3 words.txt output.txt".

Mice

Mouse clicks are another kind of input used by programs. Java makes it quite easy to arrange for your programs to receive and respond to mouse clicks. In this section of the lab, we'll look at how this is done.

Take a look at ClickableWindow.java. There are several new ideas in this program:

• Instead of using a Canvas object for drawing, we are using the JFrame class, Java's standard class for creating "frame windows" (i.e. windows with title bars). Each Canvas object contains a JFrame object, so in some ways, you'll be familiar with the JFrame methods. The window-related methods from Canvas will be the same in JFrame. The drawing methods (e.g. fillOval), however, appear not in JFrame but in the Graphics class. See the discussion of the paint method below.
• Our ClickableWindow class is a type of JFrame (that's what the "extends JFrame" is about). This is an example of inheritance (see sections 8.1-8.3 of the textbook). In this case, ClickableWindow inherits all the properties from its parent class JFrame. We'll talk more about inheritance on Monday.
• ClickableWindow also implements the MouseListener interface (see section 6.5 of your textbook for information on interfaces). The idea here is that any class that implements the MouseListener interface has responsibilities (must include the methods mousePressed, mouseReleased, mouseClicked, mouseExited, mouseEntered, and mouseDragged), but in exchange, the class gets benefits (these same methods will get called automatically when mouse actions occur).
• There's a method called paint that gets called whenever the window needs to be redrawn in part or fully. You have been shielded from the paint method by the Canvas class. Again, this is something we will discuss further next week, but for now, don't worry too much about it. Just note that the kinds of drawing operations you have done with the Canvas class can be done inside paint using the Graphics object passed as a parameter to paint.

That's a lot of unfamiliar stuff. But the heart of the matter is that the mouse-related methods in the ClickableWindow class will get called automatically when mouse events occur. To see it in action, try the following:

• Compile ClickableWindow.java.
• Run it with "java ClickableWindow". Click on the window and watch what happens.
• To see exactly which methods get called when, put a System.out.println call at the beginning of each method in ClickableWindow. Compile and run again. As you click on the window, watch what gets printed in the terminal window. Experiment for a while (what happens if you press and hold the mouse? how can you get mouseDragged to get called? etc.).
• Write a little code to make one string appear when you press the mouse down, and a different string appear when you release the mouse.
• What happens when you comment out the addListener line in the constructor? Why?
• What's the deal with the setDefaultCloseOperation call in main?

Keys

Keystrokes are handled in a way that's very similar to the handling of mouse events. Experiment with TypeableWindow.java to learn more about the KeyListener interface. Note that to get the program to do anything interesting, you have to type "r" or "g" or "b".

• How does the behavior of the program differ if you move the code in keyTyped to keyPressed or keyReleased?
• How does the switch statement work? (See section 5.4 of your textbook for details.) Try modifying it to add a new color/key combination to the list of options. Also, remove one or more of the break statements and see what that does to the program.
• What does the Java documentation of the KeyListener interface have to say about the difference between keyTyped and keyPressed?
• Put System.out.println statements in each of the key-event methods. Now try to get the program to call keyPressed and keyTyped in whatever combinations are possible. In particular, is it possible to generate many keyTyped events for a single keyPressed event?