À partir de la version 2026.2, l’ouverture d’un projet situé dans Windows Subsystem for Linux, ou WSL, depuis IntelliJ IDEA, WebStorm et PhpStorm mène à ce que JetBrains appelle le mode Native. Dans ce mode, l’IDE reste une application exécutée sur Windows, tandis qu’un petit agent au sein de WSL se charge d’exécuter les opérations sur les fichiers et les processus logiciels pour son compte. L’entreprise indique qu’il s’agit actuellement du point d’entrée recommandé, tandis que l’option Remote Development reste disponible depuis l’écran d’accueil, mais n’est plus la méthode privilégiée pour ouvrir des projets WSL.
Il ne s’agit pas seulement d’un changement de nom dans l’interface utilisateur. La prise en charge d’un projet Linux situé dans WSL exige que l’environnement de développement accède aux fichiers, exécute les outils avec les bons chemins, gère les variables d’environnement et lance les processus de compilation, de débogage et de profilage, tout en maintenant une latence suffisamment faible pour que l’expérience paraisse naturelle. JetBrains explique que les méthodes précédentes utilisaient des architectures différentes selon le point d’entrée, ce qui entraînait des écarts de performances et de comportement entre les produits et les scénarios.
Pourquoi le parcours 9P ne suffit-il plus ?
Dans l’approche précédente, les applications JetBrains sur Windows accédaient aux fichiers WSL via le protocole de système de fichiers 9P, tandis que la classe GeneralCommandLine se chargeait de normaliser les commandes exécutées dans l’environnement Linux. Cela permettait d’utiliser l’IDE avec des projets WSL, mais faisait transiter une grande partie des opérations de lecture et d’indexation par la frontière entre Windows et la machine virtuelle qui héberge WSL.
Selon JetBrains, trois problèmes principaux sont apparus. Premièrement, 9P n’affiche pas correctement les liens symboliques Linux via le chemin \wsl$, ce qui peut empêcher l’IDE de résoudre ou d’indexer certaines arborescences. Ce problème touche les environnements qui utilisent des liens symboliques, comme les espaces de travail pnpm, les environnements virtuels Python et les dépôts Composer reposant sur des chemins. Deuxièmement, l’analyse de Microsoft Defender lors de l’accès peut rallonger de plusieurs dizaines de secondes la lecture des fichiers WSL. Troisièmement, le protocole ajoute une latence notable aux opérations qui manipulent un grand nombre de petits fichiers, comme l’indexation.
En outre, la couche d’exécution des commandes a obligé les développeurs de la plateforme à gérer des sémantiques propres à WSL dans différentes parties de la base de code. JetBrains estime que cela a rendu l’approche plus difficile à faire évoluer et à maintenir, au lieu d’en faire une base unifiée pour les environnements de travail non locaux.
Qu’a apporté Remote Development ?
Remote Development a traité le problème dans le sens inverse : le backend complet de l’IDE est déplacé dans WSL, tandis qu’un client reste sur Windows pour afficher l’interface et recevoir les entrées de l’utilisateur. Les deux parties communiquent via le protocole JetBrains RD, qui transfère dans les deux sens les modèles d’événements ainsi que l’état de l’éditeur et du projet. Les opérations lourdes, comme l’indexation, l’analyse, la compilation, le débogage et les opérations de contrôle de version, sont exécutées dans WSL, à proximité des fichiers.
Cette conception a supprimé la dépendance directe à 9P pour l’accès aux fichiers, mais a introduit un autre coût. JetBrains indique que le backend nécessite environ 2 gigaoctets d’espace disque supplémentaire, en plus du temps nécessaire à son téléchargement et à son installation dans WSL. De même, l’interaction permanente entre le client et le backend impose un transfert continu de l’état de l’interface et des entrées de l’utilisateur, ce qui peut se répercuter sur la réactivité. Le développement du produit lui-même exige de séparer des parties du code entre le client et le serveur, ce qui peut provoquer des retards ou des gels dans les interfaces dynamiques si certains modules restent non divisés.
Comment fonctionne le mode Native ?
La nouvelle approche repose sur un agent appelé IJent. L’agent exécute les opérations sur les fichiers et les processus logiciels au sein de l’environnement cible, au lieu de les faire transiter par 9P ou par des couches d’exécution générales. JetBrains le décrit comme un petit composant écrit en Rust, ce qui réduit le besoin de dépendances d’exécution supplémentaires comme Java ou Kotlin dans WSL ou les conteneurs.
IJent utilise une couche de transport fondée sur Stdio, qui est portable et ne nécessite pas l’ouverture de ports de pare-feu, tandis que les sockets Hyper-V dans WSL offrent un chemin plus rapide, notamment lors du transfert d’un grand nombre de fichiers. Comme les opérations du système de fichiers sont exécutées au sein même de l’environnement Linux, le traitement des chemins et des liens symboliques se rapproche davantage des sémantiques Linux natives. Les extensions tierces en bénéficient également lorsque leurs opérations sur les fichiers passent par IJent.
IJent est associé à l’API EelApi, conçue par JetBrains pour masquer la différence entre les environnements locaux et distants aux développeurs de la plateforme et aux auteurs d’extensions. Selon ce modèle, le même code peut gérer un environnement local, WSL, Docker ou Dev Container sans ajouter de logique propre à chaque environnement. L’entreprise indique qu’IJent implémente l’API EelApi et en fournit les fonctionnalités effectives.
Que disent les tests ?
JetBrains a comparé le mode 9P et le mode IJent lors d’un test d’ouverture à froid du projet spring-framework, qui comprend 23 sous-projets et 8 191 fichiers source. Les mesures ont été réalisées sur Windows 11 avec WSL 2, Ubuntu 24.04 et la version IntelliJ IDEA Ultimate 263.SNAPSHOT, et les résultats correspondent à la médiane de cinq exécutions.
- Prêt à travailler : le temps est passé de 18,5 secondes à 11,5 secondes, soit une amélioration de 38 %.
- Analyse de l’arborescence du projet : le temps est passé de 8,1 secondes à 3,7 secondes, soit 54 % de moins.
- Indexation des fichiers : le temps est passé de 10,8 secondes à 8,4 secondes, soit une amélioration de 22 %.
- Lecture du contenu des fichiers : le temps est passé de 12,2 secondes à 5,7 secondes, soit 53 % de moins.
L’entreprise précise qu’un petit projet comprenant peu de fichiers n’a pas montré de différence mesurable lors du même test. Le gain pratique le plus important concerne donc les projets volumineux ou les flux de travail qui impliquent des accès répétés à un grand nombre de fichiers.
Qu’est-ce que cela signifie pour les développeurs ?
Le changement le plus important consiste à unifier le point d’entrée et l’architecture recommandée, et non à supprimer immédiatement toutes les options précédentes. L’utilisateur qui ouvre directement un projet WSL dans les produits pris en charge obtient le mode Native, tandis que Remote Development reste utile pour ceux qui choisissent cette approche ou qui ont besoin du modèle séparant le client et le backend. Quant à l’exécution de l’IDE lui-même via WSLg, JetBrains indique qu’elle est techniquement possible, mais qu’il ne s’agit pas d’un flux de travail pris en charge au premier niveau, en raison de limites liées au rendu, à la gestion des fenêtres et des entrées, ainsi qu’à la dépendance de l’application à une couche d’affichage Linux au sein de Windows.
Les résultats publiés indiquent une amélioration sensible pour certaines opérations, mais la portée du test est limitée à un projet, un environnement et une version déterminés. Les chiffres ne démontrent donc pas une supériorité constante pour tous les projets ou toutes les extensions. De plus, l’adoption de la nouvelle architecture dans davantage de produits JetBrains est toujours en cours, ce qui fait de la compatibilité des extensions et de leur comportement dans les différents environnements un point à surveiller.