Java Debugger

Since there is lot of high class debugger available with GUI, we never bother to use Debugger provided by JDK itself. Actually I also get to use of this someday back. Luckily lot of things available to use and some good options but some error message really wired you. But good if you want to look into those dirty threads and stack calls. Anyways lets try for some basics.

I have written a small code to debug(really don't have anything in the code to debug :) )

public class TestForJDB {

String stringJDB;

public static void main(String[] args)

{

TestForJDB test4jdb = new TestForJDB();

test4jdb.setString("test for JDB");

String getstring = test4jdb.getString();

String returnString = test4jdb.toString();

}

public TestForJDB()

{

System.out.println("Testing for JDB ");

}

public String getString()

{

return stringJDB;

}

public void setString(String value)

{

stringJDB = value;

}

public String toString()

{

return stringJDB ;

}

}

Now lets start jdb. Remember compile with -g option so that class file will get the debug informations.

E:\Program Files\Java\jdk1.6.0\bin>jdb TestForJDB

Initializing jdb ...

>

Putting some breakpoints. We have 2 ways either by line number or by method name.

> stop at TestForJDB:4

Deferring breakpoint TestForJDB:4.

It will be set after the class is loaded.

> stop at TestForJDB:11

Deferring breakpoint TestForJDB:11.

It will be set after the class is loaded.

> stop at TestForJDB:16

Deferring breakpoint TestForJDB:16.

It will be set after the class is loaded.

> stop at TestForJDB:20

Deferring breakpoint TestForJDB:20.

It will be set after the class is loaded.

> stop at TestForJDB:24

Deferring breakpoint TestForJDB:24.

It will be set after the class is loaded.

Now lets go ahead and run the class file

> run TestForJDB

It will show you some crappy information. Anyway, lets try to look into the methods available:

main[1] methods TestForJDB

** methods list **

TestForJDB main(java.lang.String[])

TestForJDB ()

TestForJDB getString()

TestForJDB setString(java.lang.String)

TestForJDB toString()

java.lang.Object ()

java.lang.Object registerNatives()

java.lang.Object getClass()

java.lang.Object hashCode()

java.lang.Object equals(java.lang.Object)

java.lang.Object clone()

java.lang.Object toString()

java.lang.Object notify()

java.lang.Object notifyAll()

java.lang.Object wait(long)

java.lang.Object wait(long, int)

java.lang.Object wait()

java.lang.Object finalize()

java.lang.Object ()

main[1] step

>

Step completed: "thread=main", TestForJDB.main(), line=6 bci=0

6 TestForJDB test4jdb = new TestForJDB();

Something unique to see here, bci = 0, what does that mean ? Don't know actually. BCI is Byte code Instrumentation and probably help if you want to go for native level debugging.

list command will tell you the current position of the debugger.

main[1] list

2 String stringJDB;

3

4 public static void main(String[] args)

5 {

6 => TestForJDB test4jdb = new TestForJDB();

7 test4jdb.setString("test for JDB");

8 String getstring = test4jdb.getString();

9 String returnString = test4jdb.toString();

10 }

11 public TestForJDB()

locals, a useful command will tell you the Methods arguments and local variable at that break point.

main[1] locals

Method arguments:

args = instance of java.lang.String[0] (id=331)

Local variables:

There are many other options like dump, step up which are useful for serious debugging. Quite Strange to know that such a tool was introduced in JDK 1.2. If you want to look into the architecture of JDB then visit this site: http://java.sun.com/j2se/1.5.0/docs/guide/jpda/index.html