Ab Version 2026.2 führt das Öffnen eines Projekts, das sich im Windows Subsystem for Linux oder WSL befindet, aus IntelliJ IDEA, WebStorm und PhpStorm heraus in den von JetBrains so bezeichneten Native-Modus. In diesem Modus bleibt die IDE eine unter Windows ausgeführte Anwendung, während ein kleiner Agent innerhalb von WSL Datei- und Programmprozesse in ihrem Auftrag ausführt. Nach Angaben des Unternehmens ist dies derzeit der empfohlene Einstieg. Die Option Remote Development bleibt auf dem Willkommensbildschirm 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 in WSL vorhandenen Linux-Projekts erfordert, dass die Entwicklungsumgebung auf Dateien zugreift, Werkzeuge mit den richtigen Pfaden ausführt, Umgebungsvariablen verwaltet sowie Build-, Debugging- und Profiling-Prozesse ausführt, während die Reaktionszeit niedrig genug bleibt, damit sich die Nutzung natürlich anfühlt. JetBrains erklärt, dass frühere Methoden je nach Einstiegspunkt unterschiedliche Architekturen verwendeten, was zu Unterschieden bei Leistung und Verhalten zwischen Produkten und Szenarien führte.
Warum reicht der 9P-Pfad nicht mehr aus?
Beim ä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, allerdings wurde ein großer Teil der Lese- und Indizierungsvorgänge über die Grenze zwischen Windows und der virtuellen Maschine, in der WSL gehostet wird, übertragen.
JetBrains zufolge traten drei Hauptprobleme auf. Erstens stellt 9P Linux-Symlinks über den Pfad \\wsl$ nicht korrekt dar, was die IDE daran hindern kann, bestimmte Verzeichnisbäume aufzulösen oder zu indizieren. Davon sind Umgebungen betroffen, die Symlinks verwenden, etwa pnpm-Arbeitsbereiche, virtuelle Python-Umgebungen und Composer-Repositories, die auf Pfade angewiesen sind. Zweitens kann die Prüfung durch Microsoft Defender beim Zugriff die Lesedauer von WSL-Dateien um Dutzende Sekunden verlängern. Drittens fügt das Protokoll Vorgängen mit einer großen Anzahl kleiner Dateien, etwa der Indizierung, eine spürbare zusätzliche Zeit hinzu.
Auch die Ausführungsschicht für Befehle zwang die Plattformentwickler dazu, in verschiedenen Teilen der Codebasis mit WSL-spezifischer Semantik umzugehen. JetBrains ist der Ansicht, dass dies den Ansatz schwieriger erweiterbar und wartbar machte, anstatt eine einheitliche Grundlage für nichtlokale Arbeitsumgebungen zu bilden.
Was fügte Remote Development hinzu?
Remote Development löste das Problem aus der entgegengesetzten Richtung: Das vollständige IDE-Backend wird nach WSL verlagert, während unter Windows ein Client verbleibt, der die Benutzeroberfläche anzeigt und Benutzereingaben entgegennimmt. Die beiden Seiten kommunizieren über das JetBrains-RD-Protokoll, das Ereignismodelle sowie den Zustand des Editors und des Projekts in beide Richtungen überträgt. Schwere Vorgänge wie Indizierung, Analyse, Build, Debugging und Versionskontrolloperationen finden hingegen innerhalb von WSL in der Nähe der Dateien statt.
Dieses Design beseitigte die direkte Abhängigkeit von 9P für den Dateizugriff, führte jedoch andere Kosten ein. JetBrains zufolge benötigt das Backend etwa 2 Gigabyte zusätzlichen Speicherplatz auf der Festplatte, zusätzlich zur Zeit für Download und Installation innerhalb von WSL. Außerdem erfordert die kontinuierliche Interaktion zwischen Client und Backend eine dauerhafte Übertragung des Zustands der Benutzeroberfläche und der Benutzereingaben, was sich auf die Reaktionsfähigkeit auswirken kann. Die Produktentwicklung selbst muss Code zwischen Client und Server aufteilen. Wenn einige Module nicht aufgeteilt bleiben, kann dies bei dynamischen Benutzeroberflächen zu Verzögerungen oder eingefrorenen Ansichten führen.
Wie funktioniert der Native-Modus?
Der neue Ansatz basiert auf einem Agenten namens IJent. Dieser Agent führt Datei- und Programmprozesse 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 reduziert.
IJent verwendet eine auf Stdio basierende Transportschicht, die portabel ist und keine geöffneten Firewall-Ports erfordert. Hyper-V-Sockets in WSL bieten dabei einen schnelleren Pfad, insbesondere bei der Übertragung großer Dateimengen. Da Dateisystemoperationen innerhalb derselben Linux-Umgebung ausgeführt werden, entspricht 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 umgehen, ohne für jede Umgebung eigene Logik hinzufügen zu müssen. Das Unternehmen erklärt, dass IJent die EelApi-Schnittstelle 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 basierten auf dem Median von fünf Ausführungen.
- Arbeitsbereitschaft: Die Zeit sank von 18,5 Sekunden auf 11,5 Sekunden, eine Verbesserung von 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 von 22 %.
- Lesen des Dateiinhalts: 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-Modus. Remote Development bleibt für Nutzer nützlich, die diesen Weg wählen oder ein getrenntes Client- und Backend-Modell benötigen. Was die Ausführung der IDE selbst über WSLg betrifft, erklärt JetBrains, dass dies technisch möglich, aber kein erstklassig unterstützter Arbeitsablauf ist, und zwar aufgrund von Einschränkungen bei Darstellung, Fensterverwaltung und Eingabe sowie der Abhängigkeit der Anwendung von einer Linux-Anzeigeschicht innerhalb von Windows.
Die veröffentlichten Ergebnisse weisen auf eine spürbare Verbesserung bei einigen Vorgängen hin, der Testumfang ist jedoch auf ein bestimmtes Projekt, eine bestimmte Umgebung und eine bestimmte Version begrenzt. Die Zahlen belegen daher keinen konstanten Vorteil 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 den verschiedenen Umgebungen weiter beobachtet werden müssen.