Home > Articles > Programming > Java

  • Print
  • + Share This

Enough Introduction...Let's Debug Already!

You start up your debugging session by using a specialized version of the Java interpreter. To debug a Java class, simply invoke the jdb tool with the name of the Java class you want to debug as an argument:

jdb YourClassName

The syntax above would run jdb on the class named YourClassName.class. Doing so runs the program using a special version of the Java interpreter that the debugger can interact with.

We Need Something to Debug

For purposes of studying jdb's offerings, we will use jdb on the Java class shown in Listing 1. (You can download this class here.) Although we are trying to troubleshoot a Java class, you need to make sure that jdb has access to both the .class file of you Java class as well as the source code of the class (that is, the .java source file).

Listing 1 The DebugMe class

 1 public class DebugMe {
 2   public static void main(String[] args) {
 3       DebugMe debugMe = new DebugMe();
 4       System.out.println("Example program for debugging");
 5       int a = 10;
 6       int b = 7;
 7       int c = debugMe.adder(a, b);
 8       System.out.println("Result= " + c);
 9   }
10   public int adder(int x, int y) {
11       System.out.println("Adding " + x + "+" + y);
12       int z = x + y;
13       return z;
14   }
15 }

Our class is intentionally kept simple. We have a simple adder method that adds two incoming integers and returns the sum. You'll see later why I structured the code the way I did. It is designed to demonstrate the usage of the debugger.

Compiling to Get More Info

When you want to debug an application, you need to compile your class using the –g option. This compile option specifies that extra information be added to the class file that is generated. This extra information is used in the debugging process. The –O option should not be used when compiling a class you want to debug. Using –O means that you want to optimize your class file. This optimization process might render a class file that does not necessarily match up with the class file's source code, thus not allowing us to use the debugger properly.

Let's Do Some Debugging

We can set breakpoints

  • At specific line numbers of the source code

  • When a method is called

  • When an exception is caught

Let's fire up the debugger for the class shown in Listing 1 with this command:

C:\j2sdk1.4.2_03\bin>jdb DebugMe
Initializing jdb ...
>

It is at the > prompt that we control our debugger.

Setting Breakpoints

We can set a breakpoint at the method level by using this syntax:

stop in classname.methodname

So in our case, we can use this command:

stop in DebugMe.adder 

Doing this, you will see a response of the following to specify that we want a breakpoint at the first line of the adder method of the DebugMe class:

> stop in DebugMe.adder
Deferring breakpoint DebugMe.adder.
It will be set after the class is loaded.

Similarly, we can specify that we want to add a breakpoint to a specific line number by using this syntax:

stop at classname:lineNumber

If we want to have a breakpoint at line number 7, we would use the following command:

stop at DebugMe:7

Listing and Clearing Breakpoints

You can list all the breakpoints you set by using the clear command with no arguments.

For our work above, we would see the following response:

> clear
Breakpoints set:
    breakpoint DebugMe.adder
    breakpoint DebugMe:7

If we want to remove a breakpoint, we can use this syntax:

clear classname:lineNumber

NOTE

Note that if you set your breakpoint using the stop in syntax (that is, setting at method level), you still need to specify the line number where the method begins if you want to remove it.

Beginning Execution

We begin the execution of the program by using the run command at the prompt. When we do so, we see the following:

> run
run DebugMe
Set uncaught java.lang.Throwable
Set deferred uncaught java.lang.Throwable
>
VM Started: Set deferred breakpoint DebugMe:7
Set deferred breakpoint DebugMe.adder
Example program for debugging

Breakpoint hit: "thread=main", DebugMe.main(), line=7 bci=22
7        int c = debugMe.adder(a, b);

Now that we have hit a breakpoint, we can enter some commands:

locals: As shown below, locals shows us the local variables currently in use and their values:

main[1] locals
Method arguments:
args = instance of java.lang.String[0] (id=270)
Local variables:
debugMe = instance of DebugMe(id=271)
a = 10
b = 7

Notice that because the breakpoint was defined at line 7, line 7 has not yet executed. Accordingly, we are not shown variable c because it has not been created.

print name: Shows us the value of the variable or object specified by name. If, for example, we want to see the contents of variable a:

main[1] print a
 a = 10

list: Shows some of the source before and after where the breakpoint was set. Pay particular attention to "=>", which shows where the execution is paused:

main[1] list
3        DebugMe debugMe = new DebugMe();
4        System.out.println("Example program for debugging");
5        int a = 10;
6        int b = 7;
7 =>      int c = debugMe.adder(a, b);
8        System.out.println("Result= " + c);
9    }
10   public int adder(int x, int y) {
11       System.out.println("Adding " + x + "+" + y);
12       int z = x + y;

Using the command cont, we can continue the running of the program until another breakpoint is hit. Notice that the debugger moves into the adder method because we specified a breakpoint there earlier:

main[1] cont
>
Breakpoint hit: "thread=main", DebugMe.adder(), line=11 bci=0
11       System.out.println("Adding " + x + "+" + y);

The step command allows us to move to the next line and pause execution there. Take a look at the portion of the debugging session below; we perform a series of steps followed by locals to show how our program is executed line by line, and how our local variable values are affected after each line is executed:

main[1] step
> Adding 10+7

Step completed: "thread=main", DebugMe.adder(), line=12 bci=34
12       int z = x + y;

main[1] locals
Method arguments:
x = 10
y = 7
Local variables:
main[1] step
>
Step completed: "thread=main", DebugMe.adder(), line=13 bci=38
13       return z;

main[1] locals
Method arguments:
x = 10
y = 7
Local variables:
z = 17

The exit command can be used any time in the debugger to end the debugging session.

  • + Share This
  • 🔖 Save To Your Account

Related Resources

There are currently no related titles. Please check back later.