{"slug": "println-debugging-done-right", "title": "Println Debugging Done Right", "summary": "IntelliJ IDEA 2026.2 introduces upgraded logpoints that use direct code instrumentation instead of debugger-side evaluation, enabling reliable use by AI agents and providing a new UI with console navigation. The update strengthens the foundation of println-style debugging, making it a more capable superset that supports conditional logging, stack traces, hit counters, caller filters, grouping, and saving, with full support in local and remote JVM debug sessions.", "body_md": "## IntelliJ IDEA\n\nIntelliJ IDEA – the Leading IDE for Professional Development in Java and Kotlin\n\n[IntelliJ IDEA](/idea/category/idea/)\n\n[Tips & Tricks](/idea/category/tips-tricks/)\n\n# Println Debugging Done Right\n\nThe simplest tools are often the most useful, and debugging is a prime example of this.\n\nThere 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.\n\nInserting 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.\n\n**Better foundation + modern workflows**\n\nThe 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](https://youtrack.jetbrains.com/issue/IJPL-88493)?).\n\nIn 2026.2, we’re taking logpoints further with several improvements focused less on specific use cases and more on strengthening the foundation:\n\n*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.: 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.*Agent compatibility*: 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.*New UI and navigation*\n\nAll these features are supported in both local and remote JVM debug sessions.\n\nLet’s look more closely at each of them.\n\n**A short demo**\n\nFor this demo, I set up a [mini gRPC server/client](https://github.com/flounder4130/grpc-timeout.git) 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.\n\nIn 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.\n\nSo, instead of using a breakpoint, let’s *log* the state, preferably with a coding agent doing it for us:\n\nThe agent not only sets the logpoints but also executes the run configurations, summarizes the resulting logs, finds the bug, and cleans up after itself.\n\nSince 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.\n\nHere’s a short video showing how that works:\n\n**Run from the terminal**\n\nIn 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:\n\nThe workflow is the same, this time with Claude Code:\n\n**Setting logpoints manually**\n\nSetting 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:\n\nTo find out which piece of code produced a specific line in the console, click the line and then select *Open*:\n\nIntelliJ 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](https://www.jetbrains.com/help/idea/logpoints.html#convert-breakpoint-to-logpoint) option, but now without cluttering the console with noisy messages.\n\n**How much faster have logpoints become?**\n\nMany benefits of logpoints are shared across debuggers:\n\n- Logpoints do not require source changes.\n- They are easy to turn on and off.\n- They let you inspect code that would otherwise be inconvenient to modify.\n\nIntelliJ IDEA’s implementation has many advantages beyond the basics, but performance is what stands out in this release.\n\nIf you’ve ever put a conditional or logging breakpoint in a hot path, you’ve seen the cost. With the traditional JPDA/JDWP breakpoint model, every hit suspends the application, evaluates the condition/log expression, and then resumes execution. For occasional hits this is fine, but in hot paths, this standard model becomes a bottleneck.\n\nThe overhead of traditional Java logpoints is not just a nuisance. The delay could hide a latency-sensitive failure, make a race condition disappear, or throttle the application load in a way that masks the problem. There’s a real risk that you would be debugging behavior introduced by the debugger itself.\n\nSome time ago, I wrote about [ways to work around this](https://flounder.dev/posts/troubleshoot-slow-debugging/#conditional-breakpoints-in-hot-code). Luckily, IntelliJ IDEA 2026.2 makes these hacks obsolete by instrumenting the debugged code for conditional and logging breakpoints. This chart shows the results of our internal benchmarking:\n\nIn our test set, the improvement is around 30x, making logpoints usable again in timing-sensitive code. You keep the same logpoint workflow, and so do agents, now with the performance of a regular print statement.\n\nThe best part is, you don’t need to do any setup to enjoy this speedup. IntelliJ IDEA will automatically detect logpoints that can be instrumented and do so behind the scenes in the same debug session, with no restart required.\n\n**Summary**\n\nLogpoints are still the same simple idea that makes println debugging great: Obtain the right bit of information and put it in the most accessible place. And with the new pieces, this technique becomes even more useful for both developers and AI agents.\n\nMore agent skills and debugger capabilities are on the way. If there is a debugging workflow you would like agents to handle, tell us in the comments under this post. And if you have a concrete feature request for IntelliJ IDEA, please file it in our [YouTrack](https://youtrack.jetbrains.com/issues/IDEA) so it doesn’t go unnoticed.\n\nHappy debugging!\n\n#### Subscribe to IntelliJ IDEA Blog updates", "url": "https://wpnews.pro/news/println-debugging-done-right", "canonical_source": "https://blog.jetbrains.com/idea/2026/08/println-debugging-done-right/", "published_at": "2026-08-06 11:30:00+00:00", "updated_at": "2026-08-09 13:50:14.279831+00:00", "lang": "en", "topics": ["developer-tools"], "entities": ["IntelliJ IDEA", "JetBrains", "Claude Code"], "alternates": {"html": "https://wpnews.pro/news/println-debugging-done-right", "markdown": "https://wpnews.pro/news/println-debugging-done-right.md", "text": "https://wpnews.pro/news/println-debugging-done-right.txt", "jsonld": "https://wpnews.pro/news/println-debugging-done-right.jsonld"}}