how to debug java code?

[Amisha Shah]

how can i debug java code step by step ? using command line and also using jcreator.

[Michael Lachenmaier]

Sorry, I don't know jCreator. But I use NetBeans IDE and it has comfortable debugging features, and .... IT'S FREE!!! So, try out http://www.netbeans.org/

[Justin Fox]

one way of doing it is just "System.out.println();"
you just print certain variables at different steps in the program
and you can see whats happening in that certain
method or whatever. I know many people dissagree that it's
useful, especially when you have netbeans debugger, but thats
what i do.

Justin Fox

[Jesper de Jong]

From the command line: The Java SDK includes a tool called jdb, the Java debugger. Read the documentation here. However, this tool isn't very user-friendly and I wouldn't recommend it unless there's no alternative you can use.

IDEs such as NetBeans (mentioned above) and Eclipse have very good and user-friendly debuggers which allow you to set breakpoints, step through the code, look at the values of variables etc. I've never used JCreator but probably it also has a debugger like that. Have a look at the JCreator documentation.

[Campbell Ritchie]

In JCreator you only have a debugger on the posh paid-for version, which you can try free of charge for a month.
If you have the LE version like me, you will have to follow Justin Fox's suggestion.
Look at this method which is supposed to add the sum of successive numbers (those who know a little arithmetic will remember this is not an efficient method to do this, and the more eagle-eyed Ranch members will see the reason for the out-by-one error before trying the method);

import javax.swing.JOptionPane;
 
public class AdditionTest
{
private int startNumber, endNumber;

        public AdditionTest(int startNumber, int endNumber)
{
this.startNumber = startNumber;
this.endNumber = endNumber;
                JOptionPane.showMessageDialog(null,
                       String.format("The numbers are %d and %d", startNumber, endNumber),
                       "In constructor",
                       JOptionPane.INFORMATION_MESSAGE);
}//end constructor

public void go()
{
long total = 0;
for(int i = startNumber; i < endNumber; i++)
{
                total += i;
                        System.out.printf("%d ", i);//test
                }//end for
JOptionPane.showMessageDialog(null,
String.format("The sum of the numbers from %d to %d is %d",
startNumber, endNumber, total),
"Success!", JOptionPane.INFORMATION_MESSAGE);
}//end go
}

Now, if you set it up with 0, 10, your printout reads 0 1 2 3 4 5 6 7 8 9. At this point you can see how the out-by-one error occurs. The //test bit allows you to use ctrl-F to locate all such testing code and delete it (or, for an assessment, to comment it out and show what you were up to).
The JOptionPane in the constructor is a modal dialogue; it stops processing until you click its "OK" button, so you can halt processing wherever you wish.

So, using these display methods allows you

to follow the flow of code by showing line numbers or method names,

to allow methods to run freely, if you don't put any messages in them,

and (probably most important of all), to see the values of variables and objects during the flow of processing.

I hope this is of some help.

CR

[Ulf Dittmer]

There's also an excellent debugger that's not tied to an IDE - JSwat.

[Henry Wong]

Originally posted by Justin Fox:
one way of doing it is just "System.out.println();"
you just print certain variables at different steps in the program
and you can see whats happening in that certain
method or whatever. I know many people dissagree that it's
useful, especially when you have netbeans debugger, but thats
what i do.

Don't know about other people, but I'll add an "agreement" to this.

Maybe it is because I generally work with Grids (lots of networked computers working as an unit), but I also either, do a lot of system outs, or bumping up the log4j levels, for the classes in question, on the nodes in question.

The eclipse debugger is great for the early stages, when I'm debugging certain (isolated) features, on a single node, which is running on my computer. However, this case doesn't occur very often.

Henry