1. Starting jGrasp: Most integrated development environments (IDEs) include a debugger. For this lab, you will use jGrasp. To get started:

1. Run jGrasp.
2. "Clean up" jGrasp by clicking on File and pulling down to Close All.
3. Open PhoneCard.java by clicking on File, pulling down to Open, and selecting the appropriate file and directory.
4. Open Driver.java in the same fashion.

2. Review: This part of the lab will review a few topics related to object-oriented programming in Java.

1. In the main() method in the Driver class, what kind of objects are end, now, and start?

   
   

   They are Date objects.
2. In the main() method in the Driver class, what kind of object is card?

   
   

   A PhoneCard object.
3. Where is the code for the PhoneCard class?

   
   

   In the current working directory.
4. Where is the code for the Date class?

   
   

   It is in the Java library (in the package java.util).
5. Search on-line for the documentation for the Date class. Make sure you find the documentation for the Date class that is in java.util. (There are several Data classes in the Java library.)
6. When you construct a Date object using the default constructor (i.e., the constructor that has no parameters), what properties will it have?

   
   

   It will contain the current date.
7. Where can you find information about the methods in the PhoneCard class?

   
   

   From the source code for the PhoneCard class. (It would be nice if we had the documentation in an HTML file, but the professor was too lazy to generate it.)

3. Setting-Up jGrasp for Debugging: Debuggers require special versions of .class files that are created by "compiling in debug mode". To make jGrasp compile in debug mode:

1. Click on the title bar of the window containing Driver.java to make sure that it has the focus.
2. Click on Build and "check" Debug Mode (if it is not already "checked").
3. Click on Build and pull down to Compile.

4. Setting a Breakpoint: One of the nice things about running an application in a debugger is that you can stop the execution at one or more pre-defined locations (called breakpoints). For example:

1. Click on the title bar of the window containing Driver.java to make sure that it has the focus.
2. Click in line 33 of Driver.java (the first if statement) to move the cursor to that line.
3. Right-click in line 33 of Driver.java and pull down to Toggle Breakpoint. (Note: You can also set a breakpoint by clicking on the left-most edge of a line.)
4. What happened?

   
   

   A red circle appeared on the left side of line 33.
5. Click on Build and pull down to Debug. This will run Driver and stop the execution at the breakpoint (i.e., line 33).
6. What happened?

   
   

   A blue arrow appeared on the left side of line 33 and the line was highlighted.

5. Checking State Information: Another nice thing about running an application in a debugger is that, once you stop the execution at a breakpoint, you can check state information (e.g., the value of attributes and variables). For example:

1. Click on the Variables tab on the left side of the jGrasp window.
2. Click on the "tree icon" next to Locals to expand it.
3. What is the current value of availableMillis?

   
   

   5999999
4. Enter an expression involving availableMillis in the "Eval" tab (e.g., availableMillis/2).
5. Note that the value of this expression will change whenever availableMillis changes. How might this kind of capability help when debugging?

   .
   

   It's particularly useful when you want to determine what would happen if you were to change a line of code (e.g., use a different calculation than the one you are currently using).

6. Stepping Over Lines: When running an application in a debugger, once you stop the execution at a breakpoint, you can continue the execution one "step" at a time. For example:

1. Click on the button until it is highlighted (i.e., darker). This will cause the execution to step one byte-code at a time.
2. Click on the button.
3. What happened?

   .
   

   Nothing seems to have happened. In fact, one byte-code was executed. So, the state information could have changed.
4. Repeatedly click on the button until something obvious happens.
5. What happened?

   .
   

   The blue arrow and highlight moved down to the next executable statement.
6. Click on the button. This will resume normal execution. (In this case, it will run to the end of the application since there are no more breakpoints).
7. Click on Build and pull down to Debug. This will run Driver again and stop the execution at the breakpoint (i.e., line 33).
8. Click on the button until it is not highlighted. This will cause the execution to step one statement at a time.
9. Click on the button.
10. What happened?

    .
    

    The blue arrow and highlight moved down to the next executable statement. highlighted.
11. Click on the button until the next if statement is highlighted.
12. What is the current value of availableMillis?

    .
    

    5399999
13. Click on the button to run to the end of the application.

7. Stepping Into Lines: So far, all of the "stepping" you have done has been in one method in one class. This is called "stepping over". You can also "step into" a line of code to see what happens there. For example:

1. Click on Build and pull down to Debug. This will run Driver and stop the execution at the breakpoint (i.e., line 33).
2. Click on the button.
3. Click on the button again.
4. What happened?

   .
   

   The blue arrow and highlight moved down to the next executable statement. highlighted.
5. Click on the button.
6. What happened?

   .
   

   The blue arrow and highlight moved into the startCall() in the PhoneCard class.
7. Look at the "Call Stack". It tells you what class and method you are in and where this method was called from.
8. What method is currently being executed (and what class is it in)?

   .
   

   The startCall() method in the PhoneCard class.
9. What line is currently being executed?

   
   

   102
10. Where was this method called from?

    .
    

    The main() method in the Driver class (line 35).
11. Click on the "tree icon" next to this to expand it.
12. What is the current value of balance?

    
    

    10.0
13. Click on the button.
14. Click on the "tree icon" next to callNumbers to expand it.
15. What is the current value of callNumbers[0]?

    .
    

    "540-568-1671"
16. Click on the "tree icon" next to callStarts to expand it.
17. What is the current value of callStarts[0]?

    .
    

    Since callStarts[0] is a Date object, it is a reference type and it should contain a reference. jGrasp displays an ID instead.
18. Why does it have that value?

    .
    

    Since callStarts[0] is an object it can have many attributes, making it somewhat difficult to display. You can either expand it or right-click on it and pull down to View by Name to see its attributes.
19. Click on the button twice.
20. What happened?

    .
    

    Execution returned to Driver.
21. Click on line 46 in Driver.java (i.e., the line that constructs a Date).
22. Click on the button. This will run the application to the cursor.
23. Click on the button.
24. Why didn't the debugger step into the Date constructor?

    .
    

    The debugger doesn't have the source code for the Date class.
25. Click on the button to run to the end.

8. Using the Debugger with Code You Wrote: In this part of the lab you will use teh debugger in jGrasp to execute some of your code.

1. Copy the working source code from one of the programming assignments to the working directory.
2. Set a breakpoint on the first line of main().
3. Execute your code one line at a time, monitoring the values of the important variables as you do so.
4. Based on this experience, why are these features collectively called a "debugger"?

   .
   

   Because they make it easy to trace the execution of a program and, hence, find any bugs.