Run in debug mode
When developing an application, it's often desirable to run it in debug mode:
Developers usually use the debugger built into their IDE (Eclipse, IntelliJ, and so on).
- 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.
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.
>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.