Println Debugging Done Right - The JetBrains Blog

IntelliJ IDEA

IntelliJ IDEA – the Leading IDE for Professional Development in Java and Kotlin

Follow

Follow:

Linkedin Linkedin

Bluesky Bluesky

X X

Facebook Facebook

Youtube Youtube

RSS RSS

Download

IntelliJ IDEA<br>Tips & Tricks<br>Println Debugging Done Right

Igor Kulakov

The simplest tools are often the most useful, and debugging is a prime example of this.

There are many advanced debugging techniques, and while they all have their use cases, println debugging is still the #1 choice, whether you’re doing it manually or with the help of coding agents.

Inserting a println statement to inspect a program’s state is one of the first things novice developers do, even before they hear the word "debugging". Years later, simple debug logging remains one of the most useful tools for diagnosing all sorts of problems in real codebases. And now, it’s also one of the favorite tools of coding agents.

Better foundation + modern workflows

The technique can be improved without losing its original simplicity. In fact, IntelliJ IDEA’s logpoints have long been a more capable superset of println debugging: While performing the same function, they can also be conditional, print stack traces, use hit counters and caller filters, be grouped, saved for later, and much more. If you try to imagine the most unusual debugging use case, chances are IntelliJ IDEA’s logpoints already have a feature for it (for example, did you know they can beep?).

In 2026.2, we’re taking logpoints further with several improvements focused less on specific use cases and more on strengthening the foundation:

Instrumentation instead of debugger-side evaluation: IntelliJ IDEA now instruments your code directly for conditional and logging breakpoints, removing the bottleneck that other Java debuggers have.

Agent compatibility: We’ve revised logpoints so they can be used reliably by AI agents. Together with a new bundled skill, this gives agents the guidelines and handles they need to control the debugging session and use all the logpoint features of the IDE.

New UI and navigation: The new UI makes logpoints easier to set up. In addition, the console now tracks which println or logpoint produced each logging entry, letting you navigate there.

All these features are supported in both local and remote JVM debug sessions.

Let’s look more closely at each of them.

A short demo

For this demo, I set up a mini gRPC server/client scenario, in which we’re supposed to debug the server side. For those new to logpoints, the next post in this series will feature a detailed tutorial based on this project. For now, let’s examine the new features.

In this particular case, suspending the app with a regular breakpoint is useless. If we try to do so, the timeout expires quickly, and execution follows the cancellation path, hiding the state we were going to inspect.

So, instead of using a breakpoint, let’s log the state, preferably with a coding agent doing it for us:

The agent not only sets the logpoints but also executes the run configurations, summarizes the resulting logs, finds the bug, and cleans up after itself.

Since IntelliJ IDEA tracks which logpoints belong to the agent, the agent cannot accidentally change yours. It does have full control over its own logpoints, though, including toggling them and modifying any properties that you can. When changing state is necessary for reproducing the bug, IntelliJ IDEA lets agents do that, but the skill steers the agent to avoid side effects and prefer logpoints whenever possible.

Here’s a short video showing how that works:

Run from the terminal

In the example above, we’re running the agent through the AI chat, but the same works equally well with agents in the built-in terminal or outside the IDE. Once the skill is installed, it becomes available in the agent of your choice:

The workflow is the same, this time with Claude Code:

Setting logpoints manually

Setting logpoints manually now takes a single click: Select the expression to log, and then click in the gutter between any two executable lines. If the expression is not in front of you in the editor, you can enter a custom expression afterwards:

To find out which piece of code produced a specific line in the console, click the line and then select Open:

IntelliJ IDEA will show the Open button that brings you to the corresponding code in the editor. Additionally, if it comes from an instrumented logpoint, the IDE will show the stack trace of how it got there – you get the same information as with the Log stack trace option, but now without cluttering the console with noisy messages.

How much faster have logpoints become?

Many benefits of logpoints are shared across debuggers:

Logpoints do not require source changes.

They are easy to turn on and off.

They let you inspect code that would otherwise be inconvenient to modify.

IntelliJ IDEA’s implementation has many advantages beyond the...