Run in debug mode
When developing an application, it's often desirable to run it in debug mode:
- you can suspend execution at specific points in your code (break points), and then step through the code, one line at a time.
- in addition to setting break points for specific lines of code, you can also set break points for trapping specific exceptions.
- when execution is suspended you can both examine data and change it on the fly.
- you can usually drop stack frames to move backwards in time, to previously invoked methods, without having to restart the
whole application from the beginning. This can save a lot of time.
- debugging is usually much more effective than using logging statements for analyzing problems.
Developers usually use the debugger built into their IDE (Eclipse, IntelliJ, and so on).
Note that the Java Development Kit (JDK) comes with its own
built-in debugger called jdb.
It has a command-line interface.
There are different ways you can use it:
- launch jdb with the main class of your application.
- tell jdb to connect to a second Java Runtime Environment (JRE). The second JRE can be running either locally or remotely.
For example:
Style 1:
>jdb MyMainClass
Style 2:
>java -agentlib:jdwp=transport=dt_socket,server=y,suspend=n,address=8000 MyMainClass
>jdb -attach 8000
If the target JRE is remote, then the syntax is usually like this:
>jdb -attach my-remote-host-name:8000
Your IDE uses a similar technique in the background.
IDEs have a graphical user interface into the same kind of debugging data and operations that are available to jdb.
On rare occasions, jdb might conceivably be used to investigate problems in a deployed application, where
an IDE is not available.
The javac tool has a -g option
that increases the amount of debugging information placed in compiled class files.
You usually don't need
the -g option when developing, since you can usually point your debugger to the underlying source code.