JetBrains präsentiert in einem von Igor Kulakov verfassten Beitrag einen praktischen Leitfaden zur Verwendung von Logpoints in IntelliJ IDEA 2026.2, um Fehler in Java-Anwendungen während der Ausführung zu diagnostizieren. Die Idee ähnelt dem Hinzufügen von println-Anweisungen zum Programm, jedoch ohne den Code zu ändern, die Anwendung neu zu erstellen oder erneut bereitzustellen; außerdem wird die Ausführung nicht angehalten. Dadurch eignen sie sich für die Untersuchung von Diensten, die lokal, in einem Docker-Container oder auf einem entfernten Host laufen.
Das Problem im Beispiel
Das Beispiel basiert auf einem Client und einem Server, die über gRPC kommunizieren. Der Server gibt für einige Mandanten einen falschen Rabattwert zurück. Beim Senden einer Anfrage für den Mandanten JetBrains und die Region EMEA erscheint in der Konsole ein Preiswert von 100.00 Dollar mit discount_bps=0, während der erwartete Wert 80.00 Dollar mit discount_bps=2000 ist.
Der Server wird mit Docker gestartet, wobei die Listening- und Debugging-Ports freigegeben werden; anschließend sendet der Client regelmäßig Anfragen. Nach dem Start von Server und Client kann der Entwickler den IntelliJ-IDEA-Debugger an den Prozess anhängen, selbst wenn dieser nicht aus einer lokalen Debugging-Sitzung heraus gestartet wurde. Der Erklärung zufolge kommuniziert der Debugger in lokalen Szenarien, getrennten Umgebungen und auf entfernten Hosts über einen Socket; daher ändert sich das Prinzip des Anhängens nicht abhängig davon, wo der Java-Prozess ausgeführt wird.
Wie Logpoints die Fehlerursache aufdecken
In IntelliJ IDEA 2026.2 kann ein Logpoint schneller erstellt werden, indem man im Editor-Rand zwischen zwei ausführbaren Zeilen klickt und anschließend den zu protokollierenden Ausdruck eingibt. Der Entwickler beginnt damit, Informationen vom Beginn der Anfrageverarbeitung zu protokollieren, und fügt nach und nach weitere Punkte hinzu oder ändert sie, während weiterhin Anfragen eintreffen.
Die Verfolgung der Aufrufkette führt zur Funktion discountBpsFor(). Die Ausgaben zeigen, dass der Name des Mandanten in der Form JetBrains eintrifft, während die Vergleichslogik den Wert jetbrains erwartet. Die Ausgaben zeigen außerdem, dass der Rabatt nicht angewendet wurde; das bedeutet, dass der Codezweig, der 2,000 Basispunkte zurückgibt, nicht ausgeführt wurde. Das Beispiel schlägt vor, den Vergleich mit equalsIgnoreCase zu korrigieren und anschließend das erwartete Verhalten zu testen.
Der Nutzen beschränkt sich nicht auf die Anzeige von Text in der Konsole: Beim Klicken auf eine Ausgabezeile kann IntelliJ IDEA zum Logpoint oder zum damit verbundenen Codeabschnitt navigieren. Diese Navigation funktioniert auch mit println-Anweisungen, wenn der Prozess unter dem IntelliJ-IDEA-Debugger läuft.
Wann sind sie println und Breakpoints überlegen?
Der Beitrag erklärt, dass Logpoints den Code nicht verunreinigen und keine Debugging-Anweisungen zurücklassen, die versehentlich in eine Produktionsumgebung gelangen könnten. Außerdem lässt sich ändern, was und wann protokolliert wird, einschließlich der Stichprobenerfassung wiederkehrender Ereignisse, des Hinzufügens von Protokollierung innerhalb von Abhängigkeiten und des Vermeidens kostspieliger erneuter Bereitstellungen.
Herkömmliche Breakpoints können dagegen ungeeignet sein, wenn das Anhalten des Dienstes Teil des Problems ist. Im Beispiel legt der Client eine Zeitüberschreitung für eine gRPC-Anfrage fest, und diese Zeitüberschreitung kann an den Server weitergegeben werden. Wenn der Debugger den Server anhält, läuft die Zeitüberschreitung ab und die Anfrage wechselt in den Abbruchpfad; dadurch sieht der Entwickler den Zustand, der zum Fehler geführt hat, nicht mehr. Die Verwendung eines Breakpoints erfordert dann, Anfragen nacheinander zu senden und innerhalb des Zeitüberschreitungsfensters zu arbeiten.
Im Gegensatz dazu liefern Logpoints Informationen, ohne den Server anzuhalten. Dadurch können Anfragen während ihrer Ausführung überwacht und der durch das Ablaufen der Zeitüberschreitung ausgelöste Abbruchpfad vermieden werden.
Das Verhalten während der Ausführung vorübergehend ändern
Der Beitrag verwendet Logpoints auch, um die Auswirkungen einer Korrektur zu testen oder das Verhalten des Programms vorübergehend zu ändern, weist jedoch darauf hin, dass sie in erster Linie für die Protokollierung und nicht für die Änderung der Anwendung konzipiert sind. Mithilfe von Ausdrücken mit Seiteneffekten kann der Zeitüberschreitungswert innerhalb der gRPC-Bibliothek während der Ausführung geändert werden. Das Beispiel zeigt, wie timeoutNanos auf eine Zeitüberschreitung von fünf Minuten geändert wird.
Um die Auswirkungen dieser Änderung zu begrenzen, kann sie auf Anfragen beschränkt werden, die den Header Debug enthalten, während die normale Zeitüberschreitung für alle übrigen Anfragen beibehalten wird. Das Beispiel enthält eine mehrzeilige Logik, die den Header liest und die Zeitüberschreitung nur dann zurücksetzt, wenn sein Wert übereinstimmt. Anschließend wird die Meldung Timeout reset angezeigt, um zu bestätigen, dass der Zweig besucht wurde.
Worauf sollte man achten?
JetBrains warnt davor, in Hot Paths aufwendige Berechnungen zu platzieren, da Protokollierungsausdrücke innerhalb der virtuellen Maschine selbst ausgeführt werden und hinsichtlich der Laufzeit nicht kostenlos sind. JetBrains weist darauf hin, dass IntelliJ IDEA 2026.2 die durch Instrumentierung verursachte Last des Debuggers entfernt; dadurch entfallen jedoch nicht die Kosten der Ausdrücke oder einer umfangreichen Protokollierung.
Der Beitrag weist außerdem auf die Möglichkeit hin, die Funktion Mark Object zu verwenden, um aus dem Ausdrucksfeld eines Logpoints auf beliebige Objekte zuzugreifen, sowie auf die beigefügte KI-Agentenfähigkeit ij-debugger, die die Stelle ermitteln kann, an der die Zeitüberschreitung gelesen wird, und einen Ausdruck erstellen kann, der auf Testanfragen abzielt. Dieser Ansatz ist weiterhin eine Alternative zum manuellen Verständnis und kein Beleg dafür, dass die vorübergehende Änderung in allen Umgebungen sicher ist.
Die redaktionelle Einordnung von certi.news
Der praktische Wert liegt hier nicht im Hinzufügen einer neuen Art von Protokollnachrichten, sondern darin, die Diagnose auf eine während der Ausführung veränderbare Ebene zu verlagern. Das ist besonders für entfernte Dienste oder Systeme mit Race Conditions oder Zeitüberschreitungen wichtig, bei denen das Anhalten der Ausführung das Problem selbst verbergen kann. Andererseits erfordert diese Methode Disziplin bei der Auswahl der Ausdrücke und bei der Überwachung ihrer Kosten. Außerdem sollte die Verwendung von Seiteneffekten zur Verhaltensänderung auf klar abgegrenzte und vorübergehende Debugging-Szenarien beschränkt bleiben und nicht zu einem Ersatz für die Korrektur des Quellcodes werden.