JetBrains presenta, en un artículo escrito por Igor Kulakov, una guía práctica para utilizar Logpoints dentro de IntelliJ IDEA 2026.2 para diagnosticar errores de aplicaciones Java durante la ejecución. La idea es similar a añadir instrucciones println al programa, pero sin modificar el código, reconstruir la aplicación ni volver a desplegarla; además, el proceso no detiene la ejecución. Esto los hace adecuados para inspeccionar servicios que se ejecutan localmente, dentro de un contenedor Docker o en un host remoto.
El problema que aborda el ejemplo
El ejemplo se basa en un cliente y un servidor que se comunican mediante gRPC. El servidor devuelve un valor de descuento incorrecto para algunos inquilinos. Al enviar una solicitud para el inquilino JetBrains y la región EMEA, en la consola aparece un valor de precio de 100.00 dólares con discount_bps=0, mientras que el valor esperado es de 80.00 dólares con discount_bps=2000.
El servidor se ejecuta mediante Docker, exponiendo los puertos de escucha y depuración, y después el cliente envía solicitudes periódicamente. Tras iniciar el servidor y el cliente, el desarrollador puede conectar el depurador de IntelliJ IDEA al proceso, aunque este no se haya iniciado desde una sesión de depuración local. Según la explicación, el depurador se comunica mediante un socket en situaciones locales, entornos separados y hosts remotos, por lo que el principio de conexión no cambia según dónde se ejecute el proceso Java.
¿Cómo revelan los Logpoints la causa del error?
En IntelliJ IDEA 2026.2 se puede crear un Logpoint más rápidamente haciendo clic en el margen del editor entre dos líneas ejecutables y, a continuación, introduciendo la expresión que se desea registrar. El desarrollador comienza registrando información desde el inicio del procesamiento de la solicitud y después añade o modifica puntos gradualmente mientras siguen llegando solicitudes.
El seguimiento de la cadena de llamadas conduce a la función discountBpsFor(). Las salidas revelan que el nombre del inquilino llega con el formato JetBrains, mientras que la lógica de comparación espera el valor jetbrains. Las salidas también muestran que el descuento no se aplicó, lo que significa que no se ejecutó la rama del código que devuelve un valor de 2,000 puntos básicos. El ejemplo propone corregir la comparación utilizando equalsIgnoreCase y, a continuación, probar el comportamiento esperado.
La utilidad no se limita a mostrar texto en la consola: al hacer clic en una línea de la salida, IntelliJ IDEA puede ir al Logpoint o a la parte del código relacionada con él. Esta navegación también funciona con instrucciones println si el proceso se ejecuta bajo el depurador de IntelliJ IDEA.
¿Cuándo superan a println y a los puntos de interrupción?
El artículo explica que los Logpoints no contaminan el código ni dejan instrucciones de depuración que puedan enviarse accidentalmente a un entorno de producción. También permiten cambiar qué se registra y cuándo, incluido el muestreo de eventos repetidos, añadir registros dentro de dependencias y evitar costosos redispliegues.
En cambio, los puntos de interrupción tradicionales pueden resultar inadecuados cuando detener el servicio forma parte del problema. En el ejemplo, el cliente establece un tiempo de espera para una solicitud gRPC, y este tiempo puede propagarse al servidor. Cuando el depurador detiene el servidor, el tiempo de espera expira y la solicitud pasa a la ruta de cancelación, por lo que el desarrollador deja de ver el estado que provocó el error. En ese caso, el uso de un punto de interrupción requiere enviar las solicitudes una por una y trabajar dentro de la ventana de tiempo de espera.
Por el contrario, los Logpoints proporcionan información sin suspender el servidor, lo que permite supervisar las solicitudes mientras se ejecutan y evitar activar la ruta de cancelación provocada por el vencimiento del tiempo de espera.
Modificar temporalmente el comportamiento durante la ejecución
El artículo también utiliza Logpoints para probar temporalmente el efecto de una corrección o de una modificación del comportamiento del programa, aunque advierte que están diseñados principalmente para registrar información, no para cambiar la aplicación. Mediante expresiones con efectos secundarios, es posible modificar el valor del tiempo de espera dentro de la biblioteca gRPC durante la ejecución. El ejemplo muestra cómo cambiar timeoutNanos a un tiempo de espera de cinco minutos.
Para reducir el impacto de este cambio, se puede limitar a las solicitudes que incluyan una cabecera Debug y mantener el tiempo de espera normal para el resto de las solicitudes. El ejemplo incluye lógica de varias líneas que lee la cabecera y restablece el tiempo de espera únicamente cuando su valor coincide; después muestra el mensaje Timeout reset para confirmar que se visitó la rama.
¿Qué precauciones deben tomarse?
JetBrains advierte contra la colocación de cálculos pesados en rutas críticas, porque las expresiones de registro se ejecutan dentro de la propia máquina virtual y no son gratuitas en términos de tiempo. También señala que IntelliJ IDEA 2026.2 elimina la sobrecarga que causa el depurador mediante instrumentation, pero eso no elimina el coste de las expresiones ni del registro intensivo.
El artículo también indica que es posible utilizar la función Mark Object para acceder a objetos arbitrarios desde el campo de expresión de un Logpoint, así como la habilidad adjunta del agente de inteligencia artificial ij-debugger, que puede identificar dónde se lee el tiempo de espera y crear una expresión dirigida a las solicitudes de prueba. Este enfoque sigue siendo una alternativa a la comprensión manual, no una prueba de que la modificación temporal sea segura para todos los entornos.
La lectura editorial de certi.news
El valor práctico no reside en añadir un nuevo tipo de mensajes de registro, sino en trasladar el diagnóstico a una capa que se puede modificar durante la ejecución. Esto es especialmente importante para servicios remotos o con condiciones de carrera o tiempos de espera, donde detener la ejecución puede ocultar el problema. Al mismo tiempo, el enfoque requiere disciplina al seleccionar las expresiones y supervisar su coste, y el uso de efectos secundarios para modificar el comportamiento debe limitarse a escenarios de depuración claros y temporales, sin convertirse en una alternativa a corregir el código fuente.