A partir de la versión 2026.2, abrir un proyecto ubicado dentro de Windows Subsystem for Linux, o WSL, desde IntelliJ IDEA, WebStorm y PhpStorm conduce a lo que JetBrains denomina modo Native. En este modo, el IDE sigue siendo una aplicación que se ejecuta en Windows, mientras un pequeño agente dentro de WSL se encarga de ejecutar en su nombre las operaciones de archivos y procesos. La empresa afirma que esta es actualmente la vía recomendada, mientras que la opción Remote Development sigue disponible desde la pantalla de bienvenida, aunque ya no es el método preferido para abrir proyectos de WSL.
El asunto no se limita a un cambio de nombre en la interfaz de usuario. El soporte de un proyecto Linux ubicado dentro de WSL requiere que el entorno de desarrollo acceda a los archivos, ejecute las herramientas con las rutas correctas, gestione las variables de entorno y ejecute procesos de compilación, depuración y perfilado, manteniendo al mismo tiempo una latencia suficientemente baja para que la experiencia parezca natural. JetBrains explica que los métodos anteriores utilizaban arquitecturas diferentes según el punto de entrada, lo que provocaba variaciones de rendimiento y comportamiento entre productos y escenarios.
¿Por qué la ruta 9P ya no es suficiente?
En el enfoque anterior, las aplicaciones de JetBrains en Windows accedían a los archivos de WSL mediante el protocolo de sistema de archivos 9P, mientras que la clase GeneralCommandLine se encargaba de normalizar los comandos de ejecución dentro del entorno Linux. Esto permitía ejecutar el IDE contra proyectos de WSL, pero trasladaba gran parte de las operaciones de lectura e indexación a través de la frontera entre Windows y la máquina virtual que aloja WSL.
Según JetBrains, aparecieron tres problemas principales. En primer lugar, 9P no muestra correctamente los enlaces simbólicos de Linux mediante la ruta \\wsl$, lo que puede impedir que el IDE resuelva o indexe algunos árboles. Este problema afecta a entornos que utilizan enlaces simbólicos, como los espacios de trabajo de pnpm, los entornos virtuales de Python y los repositorios de Composer que dependen de las rutas. En segundo lugar, el análisis de Microsoft Defender al acceder puede prolongar la lectura de archivos de WSL decenas de segundos. En tercer lugar, el protocolo añade un tiempo considerable a las operaciones que manejan un gran número de archivos pequeños, como la indexación.
Además, la capa de ejecución de comandos obligaba a los desarrolladores de la plataforma a gestionar semánticas específicas de WSL en distintas partes de la base de código. JetBrains considera que esto hizo que el enfoque fuera más difícil de ampliar y mantener, en lugar de convertirlo en una base unificada para entornos de trabajo no locales.
¿Qué aportó Remote Development?
Remote Development abordó el problema desde la dirección opuesta: el backend completo del IDE se traslada a WSL, mientras que en Windows permanece un cliente que muestra la interfaz y recibe las entradas del usuario. Ambas partes se comunican mediante el protocolo JetBrains RD, que transmite modelos de eventos y el estado del editor y del proyecto en ambas direcciones. Las operaciones pesadas, como la indexación, el análisis, la compilación, la depuración y las operaciones de control de versiones, se realizan dentro de WSL, cerca de los archivos.
Este diseño eliminó la dependencia directa de 9P para acceder a los archivos, pero añadió otro coste. JetBrains afirma que el backend necesita aproximadamente 2 gigabytes adicionales de espacio en disco, además del tiempo necesario para descargarlo e instalarlo dentro de WSL. Asimismo, la interacción continua entre el cliente y el backend exige transferir constantemente el estado de la interfaz y las entradas del usuario, lo que puede afectar a la capacidad de respuesta. El desarrollo del propio producto también requiere separar partes del código entre el cliente y el servidor, lo que puede provocar retrasos o bloqueos en interfaces dinámicas si algunos módulos siguen sin dividirse.
¿Cómo funciona el modo Native?
El nuevo enfoque se basa en un agente llamado IJent. El agente ejecuta las operaciones de archivos y procesos dentro del entorno de destino, en lugar de pasarlas mediante 9P o capas de ejecución generales. JetBrains lo describe como un componente pequeño escrito en Rust, lo que reduce la necesidad de dependencias de ejecución adicionales, como Java o Kotlin, dentro de WSL o los contenedores.
IJent utiliza una capa de transporte basada en Stdio, que es portable y no requiere abrir puertos del cortafuegos, mientras que los sockets de Hyper-V en WSL proporcionan una ruta más rápida, especialmente al transferir grandes cantidades de archivos. Como las operaciones del sistema de archivos se ejecutan dentro del propio entorno Linux, el tratamiento de las rutas y los enlaces simbólicos se acerca más a la semántica nativa de Linux. Las extensiones externas también se benefician de ello cuando sus operaciones de archivos pasan por IJent.
IJent está vinculado a la interfaz EelApi, que JetBrains diseñó para ocultar la diferencia entre entornos locales y remotos a los desarrolladores de la plataforma y a los autores de extensiones. Según este modelo, el mismo código puede trabajar con un entorno local, WSL, Docker o Dev Container sin añadir lógica específica para cada entorno. La empresa afirma que IJent implementa la interfaz EelApi y proporciona sus funciones reales.
¿Qué dicen las pruebas?
JetBrains comparó los modos 9P e IJent en una prueba de apertura en frío del proyecto spring-framework, que contiene 23 subproyectos y 8.191 archivos fuente. Las mediciones se realizaron en Windows 11 con WSL 2, Ubuntu 24.04 e IntelliJ IDEA Ultimate 263.SNAPSHOT, y los resultados utilizaron la mediana de cinco ejecuciones.
- Preparación para trabajar: el tiempo disminuyó de 18,5 segundos a 11,5 segundos, una mejora del 38 %.
- Análisis del árbol del proyecto: disminuyó de 8,1 segundos a 3,7 segundos, es decir, un 54 % menos.
- Indexación de archivos: disminuyó de 10,8 segundos a 8,4 segundos, una mejora del 22 %.
- Lectura del contenido de los archivos: disminuyó de 12,2 segundos a 5,7 segundos, es decir, un 53 % menos.
La empresa advierte que un proyecto pequeño con pocos archivos no mostró una diferencia medible en la misma prueba. Por tanto, la mayor ganancia práctica corresponde a los proyectos grandes o a los flujos de trabajo en los que se repite el acceso a un gran número de archivos.
¿Qué significa esto para los desarrolladores?
El cambio más importante es la unificación del punto de entrada y de la arquitectura recomendada, no la eliminación inmediata de todas las opciones anteriores. El usuario que abre directamente un proyecto de WSL en los productos compatibles obtiene el modo Native, mientras que Remote Development sigue siendo útil para quienes eligen esta vía o necesitan un modelo con el cliente y el backend separados. En cuanto a ejecutar el propio IDE mediante WSLg, JetBrains afirma que técnicamente es posible, pero no constituye un flujo de trabajo compatible de primera clase debido a limitaciones relacionadas con los gráficos, la gestión de ventanas y la entrada, además de la dependencia de la aplicación de una capa de presentación Linux dentro de Windows.
Los resultados publicados indican una mejora tangible en algunas operaciones, pero el alcance de la prueba está limitado a un proyecto, un entorno y una versión concretos. Por tanto, las cifras no demuestran una superioridad constante para todos los proyectos o extensiones. Asimismo, la adopción de la nueva arquitectura en más productos de JetBrains sigue en curso, por lo que la compatibilidad de las extensiones y su comportamiento en distintos entornos son aspectos que conviene seguir.