Dans un article rédigé par Igor Kulakov, JetBrains propose un guide pratique de l’utilisation des Logpoints dans IntelliJ IDEA 2026.2 pour diagnostiquer les erreurs des applications Java pendant leur exécution. L’idée ressemble à l’ajout d’instructions println au programme, mais sans modifier le code, reconstruire l’application ou la redéployer, et l’exécution n’est pas interrompue. Cela les rend adaptés à l’inspection de services fonctionnant localement, dans un conteneur Docker ou sur un hôte distant.
Le problème traité par l’exemple
L’exemple repose sur un client et un serveur qui communiquent via gRPC. Le serveur renvoie une valeur de remise incorrecte pour certains locataires. Lorsqu’une requête concernant le locataire JetBrains et la région EMEA est envoyée, la console affiche un prix de 100.00 dollars avec discount_bps=0, alors que la valeur attendue est de 80.00 dollars avec discount_bps=2000.
Le serveur est lancé avec Docker, en exposant les ports d’écoute et de débogage, puis le client envoie périodiquement des requêtes. Après le démarrage du serveur et du client, le développeur peut attacher le débogueur d’IntelliJ IDEA au processus, même si celui-ci n’a pas été lancé depuis une session de débogage locale. Selon l’explication, le débogueur communique via un socket dans les scénarios locaux, les environnements séparés et les hôtes distants ; le principe de l’attachement ne change donc pas selon l’endroit où s’exécute le processus Java.
Comment les Logpoints révèlent-ils la cause de l’erreur ?
Dans IntelliJ IDEA 2026.2, il est possible de créer plus rapidement un Logpoint en cliquant dans la marge de l’éditeur entre deux lignes exécutables, puis en saisissant l’expression à journaliser. Le développeur commence par enregistrer des informations au début du traitement de la requête, puis ajoute ou modifie progressivement des points tandis que les requêtes continuent d’arriver.
Le suivi de la chaîne d’appels mène à la fonction discountBpsFor(). Les sorties révèlent que le nom du locataire arrive sous la forme JetBrains, tandis que la logique de comparaison attend la valeur jetbrains. Les sorties montrent également que la remise n’a pas été appliquée, ce qui signifie que la branche du code qui renvoie 2,000 points de base n’a pas été exécutée. L’exemple propose de corriger la comparaison en utilisant equalsIgnoreCase, puis de tester le comportement attendu.
L’intérêt ne se limite pas à l’affichage du texte dans la console : en cliquant sur une ligne de sortie, IntelliJ IDEA peut accéder au Logpoint ou à la partie du code qui lui est associée. Cette navigation fonctionne également avec les instructions println lorsque le processus s’exécute sous le débogueur d’IntelliJ IDEA.
Quand sont-ils préférables à println et aux points d’arrêt ?
L’article explique que les Logpoints ne polluent pas le code et ne laissent pas derrière eux des instructions de débogage susceptibles d’être envoyées par erreur en production. Il est également possible de modifier ce qui est enregistré et le moment où cela l’est, notamment en échantillonnant les événements répétitifs, en ajoutant une journalisation dans les dépendances et en évitant les redéploiements coûteux.
Les points d’arrêt traditionnels peuvent toutefois être inadaptés lorsque l’arrêt du service fait partie du problème. Dans l’exemple, le client définit un délai d’expiration pour une requête gRPC, et ce délai peut être transmis au serveur. Lorsque le débogueur arrête le serveur, le délai expire et la requête passe au chemin d’annulation ; le développeur ne voit alors plus l’état qui a conduit à l’erreur. L’utilisation d’un point d’arrêt nécessite dans ce cas d’envoyer les requêtes une par une et de travailler dans la fenêtre du délai d’expiration.
À l’inverse, les Logpoints fournissent des informations sans suspendre le serveur, ce qui permet de surveiller les requêtes pendant leur exécution et d’éviter l’activation du chemin d’annulation provoqué par l’expiration du délai.
Modifier temporairement le comportement pendant l’exécution
L’article utilise également les Logpoints pour tester temporairement l’effet d’une correction ou d’une modification du comportement du programme, tout en précisant qu’ils sont conçus principalement pour la journalisation et non pour modifier l’application. En utilisant des expressions ayant des effets secondaires, il est possible de modifier la valeur du délai dans la bibliothèque gRPC pendant l’exécution. L’exemple montre la modification de timeoutNanos pour définir un délai de cinq minutes.
Pour limiter l’effet de cette modification, il est possible de la restreindre aux requêtes qui portent un en-tête Debug, tout en conservant le délai normal pour les autres requêtes. L’exemple inclut une logique sur plusieurs lignes qui lit l’en-tête et ne réinitialise le délai que lorsque sa valeur correspond, puis affiche le message Timeout reset afin de confirmer que la branche a été visitée.
À quoi faut-il faire attention ?
JetBrains met en garde contre l’utilisation de calculs lourds dans les chemins critiques, car les expressions de journalisation sont exécutées dans la machine virtuelle elle-même et ne sont pas gratuites en matière de temps d’exécution. L’entreprise précise qu’IntelliJ IDEA 2026.2 élimine la surcharge causée par le débogueur via l’instrumentation, mais cela ne supprime pas le coût des expressions ni celui d’une journalisation intensive.
L’article indique également qu’il est possible d’utiliser la fonctionnalité Mark Object pour accéder à des objets arbitraires depuis un champ d’expression Logpoint, ainsi que la compétence de l’agent d’intelligence artificielle ij-debugger fournie, qui peut déterminer où le délai est lu et créer une expression ciblant les requêtes de test. Cette approche reste une alternative à la compréhension manuelle, et non une preuve que la modification temporaire est sûre dans tous les environnements.
La lecture éditoriale de certi.news
La valeur pratique ne réside pas ici dans l’ajout d’un nouveau type de messages de journal, mais dans le transfert du diagnostic vers une couche modifiable pendant l’exécution. Cela est particulièrement important pour les services distants, les situations de concurrence ou les scénarios soumis à des délais d’expiration, où l’arrêt de l’exécution peut masquer précisément le problème. En revanche, cette méthode exige de la discipline dans le choix des expressions et dans le suivi de leur coût ; l’utilisation d’effets secondaires pour modifier le comportement doit également rester limitée à des scénarios de débogage clairs et temporaires, plutôt que de devenir une alternative à la correction du code source.