Practical Debugging Techniques in IntelliJ IDEA and jdb for Java Development

Debugging is a fundamental skill in software development. The term "debug" literally means removing bugs, and mastering debugging allows developers to quickly locate and fix issues in code. Understanding code does not guarantee the ability to write bug‑free code; therefore, learning basic debugging techniques is essential.

Regardless of whether you use IntelliJ IDEA or Eclipse, a debugger is a standard tool. Proper use of the debugger’s stepping and breakpoint features can locate problems faster than relying on logs, and System.out.println should not be used as a debugging method in development environments.

1. Practical IDEA Debugging Techniques

If you develop Java, you have probably heard of IntelliJ IDEA. After switching from Eclipse to IDEA, many developers become loyal fans because of its powerful debugging panel, which consists of five parts: step tracing, breakpoint management, evaluate expression, stack & thread, and variable watch.

Step Tracing

Breakpoint Management

Evaluate Expression

Stack and Thread

Variable Watch

1.1 Step Tracing

IDEA provides many shortcuts for stepping through code. "Show Execution Point" quickly jumps to the current line being executed. "Navigate Back" returns to the previous location, which is useful after browsing many source files.

Step Over – executes the current line and skips over method bodies.

Step In / Force Step In – enters a method; Force Step In also steps into JDK methods.

Step Out – finishes the current method and stops at the caller.

Drop to Frame – removes the top stack frame, returning execution to the caller’s line (useful when you missed a critical line).

Run to Cursor / Force Run to Cursor – runs to a specific line without setting a permanent breakpoint.

Configuration for skipping system methods can be set in

Settings → Build, Execution, Deployment → Debugger → Stepping

.

1.2 Breakpoint Management

Breakpoints pause program execution at desired locations. IDEA supports line breakpoints and global (conditional) breakpoints.

1.2.1 Line Breakpoints

Suspend (All / Thread)

Condition – e.g., pause only when person.name = 'Zhangsan'.

Log message to console

Evaluate and log – replaces System.out.println with debugger‑generated logs.

Remove once hit – one‑time breakpoint.

Instance filters – pause only when the object instance matches a given ID.

Class filters

Pass count – pause after a specified number of hits.

1.2.2 Global Breakpoints

Exception breakpoints

Method breakpoints

Field watchpoints

1.3 Evaluate Expression

The "Evaluate Expression" button lets you view variable values, evaluate arbitrary expressions, or run code fragments (Expression Mode vs. Code Fragment Mode). Code fragments cannot define new methods.

1.4 Stack and Thread

The Stack view shows the call stack, while the Thread view lists all running threads. You can perform a thread dump and switch stack frames to inspect local variables and parameters.

1.5 Variable Watch

Variables can be displayed together or separately. The watch window allows you to add expressions that are evaluated continuously during debugging, and you can even modify variable values on the fly.

2. Using jdb Command‑Line Debugger

jdb is the command‑line counterpart of gdb for Java. It is included with the JDK and does not require separate installation.

2.1 jdb Basic Commands

Start debugging with jdb Test. The program pauses, waiting for commands. Set a breakpoint in Test.main with stop in Test.main, then run the program with run. Delayed breakpoints are set after the class loads.

> stop in Test.main
正在延迟断点Test.main。将在加载类后设置。
> run
运行Test
VM 已启动：设置延迟的断点：Test.main

Other breakpoint commands include stop at Test:25. Use list to view nearby source, step to step, print or dump to display values, locals to list all locals, and cont to continue.

2.2 Exploring Class File Structure

If source files are not alongside class files, specify the source path with jdb -sourcepath path/to/source Test. Class files contain basic info, constant pool, interfaces, attributes, superclass, fields, and methods. The most important attribute for debugging is the Code attribute, which includes the LineNumberTable linking bytecode to source lines.

2.3 Remote Debugging with jdb

Java programs can be started with the JDWP agent to enable remote debugging:

# java -agentlib:jdwp=transport=dt_socket,server=y,address=5005 Test
# java -agentlib:jdwp=transport=dt_shmem,server=y,address=javadebug Test

Attach the debugger with jdb -attach 5005 (socket) or jdb -attach javadebug (shared memory). On Windows, use

jdb -connect com.sun.jdi.SocketAttach:hostname=localhost,port=5005

because the default transport is shared memory.

3. About Remote Debugging

IDEA runs the debugger as a server listening on a port (e.g., 20060) and the Java program connects to it using the JDWP agent with

-agentlib:jdwp=transport=dt_socket,address=127.0.0.1:20060,suspend=y,server=n

. The same principle applies to remote debugging of Tomcat or other Java applications.

4. Java Debugging Principles and JPDA Overview

Debugging a Java program means communicating with the JVM to query its state and issue commands. The Java Platform Debugger Architecture (JPDA) consists of three layers:

JVMTI – native interface for the JVM.

JDWP – Java Debug Wire Protocol for communication.

JDI – high‑level Java Debug Interface used by debuggers.

The debugger (debugger) and the debuggee (program) interact via JDWP packets, which are translated to JVMTI calls on the target JVM and back to JDI for the debugger.

4.1 JPDA

JPDA provides a complete set of APIs for building Java debugging tools, exposing the JVM’s runtime state through a well‑defined protocol.

4.2 Connectors & Transport

JDWP supports five connector types: socket‑attaching, shared‑memory attaching, socket‑listening, shared‑memory listening, and command‑line launching. The transport can be either socket or shared memory (Windows only). The choice determines which side acts as the server.

4.3 Practical Remote Debugging

To start a program as a JDWP server, use:

# java -agentlib:jdwp=transport=dt_socket,server=y,address=5005 Test
# java -agentlib:jdwp=transport=dt_shmem,server=y,address=javadebug Test

Then connect with jdb -attach 5005 or

jdb -connect com.sun.jdi.SocketAttach:hostname=localhost,port=5005

. Conversely, you can start the debugger as a server ( jdb -listen javadebug) and have the JVM connect to it.

Summary

The article first presented common IDEA debugging tricks, then demonstrated command‑line debugging with jdb, and finally explored remote debugging and the underlying JPDA architecture, covering concepts such as JVMTI, JDWP, and JDI. By combining practical techniques with a solid understanding of the debugger’s inner workings, developers can debug more effectively.

While mastering tricks makes tool usage smoother, understanding the underlying principles prevents becoming a “tool‑only” practitioner. Combining both leads to deeper expertise.

Remember: the best code requires minimal debugging; invest in unit tests and refactoring to write clear, maintainable Java.