Ab Version 2026.2 führt das Öffnen eines Projekts, das sich im Windows Subsystem for Linux, kurz WSL, befindet, innerhalb von IntelliJ IDEA, WebStorm und PhpStorm in den von JetBrains so bezeichneten Native mode. In diesem Modus bleibt die IDE eine unter Windows ausgeführte Anwendung, während ein kleiner Agent innerhalb von WSL Datei- und Prozessoperationen in ihrem Auftrag ausführt. Nach Angaben des Unternehmens ist dies derzeit der empfohlene Einstieg. Die Option Remote Development bleibt auf dem Begrüßungsbildschirm verfügbar, ist jedoch nicht mehr die bevorzugte Methode zum Öffnen von WSL-Projekten.
Es geht dabei nicht nur um eine Änderung der Bezeichnung in der Benutzeroberfläche. Die Unterstützung eines Linux-Projekts innerhalb von WSL erfordert, dass die Entwicklungsumgebung auf Dateien zugreifen, Tools mit den richtigen Pfaden ausführen, Umgebungsvariablen verwalten sowie Build-, Debugging- und Profiling-Prozesse ausführen kann – und das bei einer ausreichend niedrigen Latenz, damit sich die Nutzung normal anfühlt. JetBrains erklärt, dass frühere Methoden je nach Einstiegspunkt unterschiedliche Architekturen verwendeten. Dies führte zu unterschiedlichen Leistungen und Verhaltensweisen zwischen Produkten und Szenarien.
Warum reicht der 9P-Weg nicht mehr aus?
Im älteren Ansatz griffen JetBrains-Anwendungen unter Windows über das 9P-Dateisystemprotokoll auf WSL-Dateien zu, während die Klasse GeneralCommandLine für die Normalisierung von Ausführungsbefehlen innerhalb der Linux-Umgebung zuständig war. Dadurch konnte die IDE mit WSL-Projekten arbeiten, ein großer Teil der Lese- und Indizierungsvorgänge wurde jedoch über die Grenze zwischen Windows und der virtuellen Maschine übertragen, in der WSL gehostet wird.
Nach Angaben von JetBrains traten drei Hauptprobleme auf. Erstens stellt 9P Linux-Symlinks über den Pfad \wsl$ nicht korrekt dar, wodurch die IDE bestimmte Verzeichnisbäume möglicherweise nicht auflösen oder indizieren kann. Dieses Problem betrifft Umgebungen, die Symlinks verwenden, etwa pnpm-Arbeitsbereiche, virtuelle Python-Umgebungen und Composer-Repositories, die auf Pfaden basieren. Zweitens kann die Prüfung durch Microsoft Defender beim Zugriff das Lesen von WSL-Dateien um mehrere zehn Sekunden verlängern. Drittens fügt das Protokoll Vorgängen, die mit einer großen Anzahl kleiner Dateien arbeiten, etwa der Indizierung, eine spürbare Latenz hinzu.
Auch die Befehlsschicht zwang Plattformentwickler dazu, in verschiedenen Teilen der Codebasis mit speziellen WSL-Semantiken umzugehen. JetBrains ist der Ansicht, dass der Ansatz dadurch schwieriger zu skalieren und zu warten war, anstatt eine einheitliche Grundlage für nicht lokale Arbeitsumgebungen zu bilden.
Was brachte Remote Development hinzu?
Remote Development löste das Problem aus der entgegengesetzten Richtung: Das vollständige Backend der IDE wird nach WSL verlagert, während unter Windows ein Client verbleibt, der die Benutzeroberfläche darstellt und Benutzereingaben entgegennimmt. Beide Seiten kommunizieren über das JetBrains-RD-Protokoll, das Ereignismodelle sowie den Editor- und Projektstatus in beide Richtungen überträgt. Aufwendige Vorgänge wie Indizierung, Analyse, Build, Debugging und Versionskontrolloperationen finden innerhalb von WSL in der Nähe der Dateien statt.
Dieses Design beseitigte die direkte Abhängigkeit von 9P für den Dateizugriff, brachte jedoch andere Kosten mit sich. JetBrains zufolge benötigt das Backend etwa 2 Gigabyte zusätzlichen Speicherplatz, zusätzlich zur Zeit für den Download und die Installation innerhalb von WSL. Die fortlaufende Interaktion zwischen Client und Backend erzeugt außerdem einen ständigen Austausch von Benutzeroberflächenstatus und Benutzereingaben, was sich auf die Reaktionsfähigkeit auswirken kann. Für die Produktentwicklung selbst müssen Codeteile zwischen Client und Server aufgeteilt werden. Wenn bestimmte Module nicht aufgeteilt bleiben, kann dies bei dynamischen Oberflächen zu Verzögerungen oder eingefrorenen Benutzeroberflächen führen.
Wie funktioniert der Native mode?
Der neue Ansatz basiert auf einem Agenten namens IJent. Der Agent führt Datei- und Prozessoperationen innerhalb der Zielumgebung aus, anstatt sie über 9P oder allgemeine Ausführungsschichten weiterzuleiten. JetBrains beschreibt ihn als kleine Komponente, die in Rust geschrieben ist und dadurch den Bedarf an zusätzlichen Laufzeitabhängigkeiten wie Java oder Kotlin innerhalb von WSL oder Containern verringert.
IJent verwendet eine auf Stdio basierende Transportschicht, die portabel ist und keine geöffneten Firewall-Ports erfordert. Hyper-V-Sockets in WSL bieten hingegen einen schnelleren Pfad, insbesondere bei der Übertragung großer Dateimengen. Da Dateisystemoperationen direkt in der Linux-Umgebung ausgeführt werden, ähneln die Verarbeitung von Pfaden und Symlinks stärker der nativen Linux-Semantik. Auch externe Plugins profitieren davon, wenn ihre Dateioperationen über IJent laufen.
IJent ist an die EelApi-Schnittstelle angebunden, die JetBrains entwickelt hat, um den Unterschied zwischen lokalen und entfernten Umgebungen für Plattformentwickler und Plugin-Autoren zu verbergen. Nach diesem Modell kann derselbe Code mit einer lokalen Umgebung, WSL, Docker oder einem Dev Container arbeiten, ohne für jede Umgebung eigene Logik hinzuzufügen. Das Unternehmen erklärt, dass IJent die EelApi implementiert und ihre tatsächlichen Funktionen bereitstellt.
Was sagen die Tests?
JetBrains verglich den 9P-Modus mit dem IJent-Modus in einem Kaltstarttest zum Öffnen des Projekts spring-framework, das 23 Teilprojekte und 8.191 Quelldateien umfasst. Die Messungen wurden unter Windows 11 mit WSL 2, Ubuntu 24.04 und der Version IntelliJ IDEA Ultimate 263.SNAPSHOT durchgeführt. Die Ergebnisse basieren auf dem Median von fünf Durchläufen.
- Arbeitsbereitschaft: Die Zeit sank von 18,5 Sekunden auf 11,5 Sekunden, eine Verbesserung um 38 %.
- Prüfung des Projektbaums: Sie sank von 8,1 Sekunden auf 3,7 Sekunden, also um 54 %.
- Dateiindizierung: Sie sank von 10,8 Sekunden auf 8,4 Sekunden, eine Verbesserung um 22 %.
- Lesen von Dateiinhalten: Die Zeit sank von 12,2 Sekunden auf 5,7 Sekunden, also um 53 %.
Das Unternehmen weist darauf hin, dass ein kleines Projekt mit wenigen Dateien im selben Test keinen messbaren Unterschied zeigte. Der größte praktische Vorteil betrifft daher große Projekte oder Arbeitsabläufe, bei denen wiederholt auf eine große Anzahl von Dateien zugegriffen wird.
Was bedeutet das für Entwickler?
Die wichtigste Änderung ist die Vereinheitlichung des Einstiegspunkts und der empfohlenen Architektur, nicht die sofortige Abschaffung aller bisherigen Optionen. Wer ein WSL-Projekt direkt in den unterstützten Produkten öffnet, erhält den Native mode. Remote Development bleibt für diejenigen nützlich, die diesen Weg wählen oder ein getrenntes Client- und Backend-Modell benötigen. Die Ausführung der IDE selbst über WSLg ist nach Angaben von JetBrains technisch möglich, stellt jedoch keinen vollständig unterstützten Arbeitsablauf erster Klasse dar, da Einschränkungen bei Grafik, Fensterverwaltung und Eingabe bestehen und die Anwendung von einer Linux-Anzeigeschicht innerhalb von Windows abhängt.
Die veröffentlichten Ergebnisse weisen auf spürbare Verbesserungen bei bestimmten Vorgängen hin, der Testumfang ist jedoch auf ein Projekt, eine Umgebung und eine bestimmte Version begrenzt. Die Zahlen belegen daher keine dauerhaft bessere Leistung für alle Projekte oder Plugins. Außerdem wird die neue Architektur weiterhin auf weitere JetBrains-Produkte ausgeweitet, wodurch die Kompatibilität und das Verhalten von Plugins in verschiedenen Umgebungen weiterhin beobachtet werden sollten.