We will begin this lab with an introduction to jdb, the Java source-level debugger. This utility will serve you well, once you learn to use it, in debugging your programs. After that, we will move onto a simple case of inheritance from an abstract class.
See the solution.
The Java source-level debugger (jdb) is a powerful tool that will allow you to control the execution of a program, examining the state of your data between steps. We will only introduce this utility during this lab: a full examination of its capabilities would take too much time. However, even the simple uses of jdb will provide powerful enough to be a great aid in understanding and debugging code.
Follow these steps to see some of what jdb can do:
Copy a file from my home directory:
cp ~sfkaplan/public/cs12/Buggy.java
Compile this program using the -g option, which generates extra information in the resultant .class file for debugging purposes:
javac -g Buggy.java
Open the Buggy.java file to see what it is supposed to do (which is, frankly, not much). Feel free to examine the code, but don't change anything -- it contains an intentional bug.
Now, at your shell, start Buggy within jdb itself:
jdb Buggy
At the new jdb prompt, just try the help, which will list the commands available within the debugger. Note that the list is long, and will fly right by!
A main purpose of a debugger is to be able to pause execution at a particular point and examine the state of the program. One way of pausing the program is to specify a method name; jdb will then pause execution whenever that method is called. Let's try pausing execution when main() itself is called:
stop in Buggy.main
Now that a breakpoint is set for main(), start running the program:
run
jdb will immediately pause execution and show you at which line it has stopped. You can use the line number to find the place within the larger source code. Better yet, you can see the entire method from within the debugger:
list
Once stopped, you can examine the state of the available variables or data members:
locals
Notice that at this point, args is the only variable available. The code will need to run further for more variables to exist.
Once execution is paused, you also want to be able to move it forward. One option is to execute a single line of code:
next
Note that this command will execute the entirety of that line of code. If there are method calls on that line, the method call will be performed and the debugger won't pause until that method has returned.
Try the locals command again. You'll see that a new variable, x, was declared and assigned. You can even examine individual elements of this array:
print x[2]
Instead of using the next command, try another one that also executes a single line of code, but will jump into a method being called on that line:
step
If you want execution simply to resume at full speed, without step-by-step control, you can do the following:
cont
The program will crash (since it has a bug)! jdb will automatically pause when the exception is generated, giving you control at that point.
Not only can you use list to see which method caused the crash, but you can also see the activation stack to see what other methods called this one, and in what order:
where
You can move through the frames to see the local variables associated with each method call using the up and down commands. Try it!
Do you see the error in the lowest frame (the one that caused the exception)? Once you do, you have to exit jdb with the quit command, edit the code, recompile, and re-run (potentially within jdb itself).
Take a look at the help information and try some of the other commands. It is also possible to have jdb print the sequence of method calls (trace methods), stop at a particular line number (with stop at), list the fields and classes of a method (methods and fields), or stop each time a particular data member is modified (watch).
You must take an abstract class that I have provided named Shape. This class is very simple: It holds a size associated with a shape, and declares an abstract method that computes the area of the shape.
Of course, the area can't be computed without knowing just which shape. You must create two subclasses, Circle and Square, which implement the area() method by computing and returning the area for those given shapes based on the size.
I have also written a small class, called CompareArea, that depends on a Square and Circle class existing. You must write your two subclasses and test them with the CompareArea class.
You can obtain my classes like so:
cp ~sfkaplan/public/cs12/Shape.java
cp ~sfkaplan/public/cs12/CompareArea.java
Once you have written and tested your two new classes, you must use the cs12-submit command to turn in your Java code. Submit this assignment as lab-3 when you use the cs12-submit command, like so:
cs12-submit lab-3 Square.java Circle.java