2026.2 sürümünden itibaren Windows Subsystem for Linux veya WSL içinde bulunan bir projeyi IntelliJ IDEA, WebStorm ya da PhpStorm içinden açmak, JetBrains'in Native mode olarak adlandırdığı moda yönlendiriyor. Bu modda IDE, Windows üzerinde çalışan bir uygulama olarak kalırken WSL içindeki küçük bir aracı dosya ve süreç işlemlerini onun adına yürütüyor. Şirket, bunun şu anda önerilen giriş yöntemi olduğunu; Remote Development seçeneğinin karşılama ekranında kullanılabilir kalmasına rağmen WSL projelerini açmanın artık tercih edilen yolu olmadığını söylüyor.
Buradaki mesele yalnızca kullanıcı arayüzündeki bir ad değişikliğinden ibaret değil. WSL içinde bulunan bir Linux projesi desteği, geliştirme ortamının dosyalara erişmesini, araçları doğru yollarla çalıştırmasını, ortam değişkenlerini yönetmesini, derleme, hata ayıklama ve profil oluşturma işlemlerini yürütmesini ve deneyimin doğal görünmesini sağlayacak kadar düşük tepki süresini korumasını gerektiriyor. JetBrains, önceki yöntemlerin giriş noktasına bağlı olarak farklı mimariler kullandığını; bunun da ürünler ve senaryolar arasında performans ve davranış farklılıklarına yol açtığını açıklıyor.
9P yolu neden artık yeterli değil?
Daha eski yaklaşımda Windows üzerindeki JetBrains uygulamaları, WSL dosyalarına 9P dosya sistemi protokolü üzerinden erişirken GeneralCommandLine sınıfı çalıştırma komutlarını Linux ortamında normalleştiriyordu. Bu, IDE'nin WSL projeleri üzerinde çalışmasını sağladı; ancak okuma ve dizinleme işlemlerinin büyük bir bölümünü Windows ile WSL'yi barındıran sanal makine arasındaki sınırdan geçirdi.
JetBrains'e göre üç temel sorun ortaya çıktı. Birincisi, 9P Linux sembolik bağlantılarını \\wsl$ yolu üzerinden doğru şekilde göstermiyor; bu da IDE'nin bazı ağaçları çözmesini veya dizinlemesini engelleyebiliyor. Bu sorun, pnpm çalışma alanları, Python sanal ortamları ve yollara dayanan Composer depoları gibi sembolik bağlantılar kullanan ortamları etkiliyor. İkincisi, erişim sırasında Microsoft Defender taraması WSL dosyalarının okunmasını onlarca saniye uzatabiliyor. Üçüncüsü ise protokol, dizinleme gibi çok sayıda küçük dosyayla çalışan işlemlere kayda değer bir süre ekliyor.
Komut çalıştırma katmanı ayrıca platform geliştiricilerini kod tabanının farklı bölümlerinde WSL'ye özgü anlamlarla ilgilenmeye zorladı. JetBrains, bunun yaklaşımın ölçeklenmesini ve bakımını, yerel olmayan çalışma ortamları için birleşik bir temel olmaktan çıkacak şekilde zorlaştırdığını düşünüyor.
Remote Development ne ekledi?
Remote Development sorunu ters yönden ele aldı: IDE'nin tam backend'i WSL'ye taşınırken Windows üzerinde arayüzü görüntüleyen ve kullanıcı girdilerini alan bir istemci kaldı. İki taraf, olay modellerini ve düzenleyici ile proje durumunu iki yönde aktaran JetBrains RD protokolü üzerinden iletişim kuruyor. Dizinleme, analiz, derleme, hata ayıklama ve sürüm kontrolü işlemleri gibi ağır işlemler ise dosyaların yakınında, WSL içinde gerçekleştiriliyor.
Bu tasarım, dosyalara erişimde 9P'ye doğrudan bağımlılığı ortadan kaldırdı; ancak başka bir maliyet ekledi. JetBrains, backend'in diskte yaklaşık 2 gigabayt ek alan gerektirdiğini ve WSL içinde indirilip kurulması için de zaman gerektiğini söylüyor. Ayrıca istemci ile backend arasındaki sürekli etkileşim, arayüz durumu ve kullanıcı girdileri için sürekli trafik gerektiriyor ve bu durum tepki süresini etkileyebiliyor. Ürünün geliştirilmesi de kod bölümlerinin istemci ile sunucu arasında ayrılmasını gerektiriyor; bazı modüller bölünmemiş kaldığında bu, dinamik arayüzlerde gecikmelere veya donmalara neden olabiliyor.
Native mode nasıl çalışıyor?
Yeni yaklaşım IJent adlı bir aracıya dayanıyor. Aracı, işlemleri 9P veya genel çalıştırma katmanları üzerinden aktarmak yerine dosya ve süreç işlemlerini hedef ortamın içinde yürütüyor. JetBrains, bunu Rust ile yazılmış küçük bir bileşen olarak tanımlıyor; bu da WSL veya kapsayıcılar içinde Java ya da Kotlin gibi ek çalışma zamanı bağımlılıklarına duyulan ihtiyacı azaltıyor.
IJent, taşınabilir olan ve güvenlik duvarı bağlantı noktalarının açılmasını gerektirmeyen Stdio tabanlı bir aktarım katmanı kullanıyor. WSL'deki Hyper-V soketleri ise özellikle çok sayıda dosya aktarılırken daha hızlı bir yol sağlıyor. Dosya sistemi işlemleri doğrudan Linux ortamının içinde yürütüldüğü için yolların ve sembolik bağlantıların işlenmesi, Linux'un yerel anlamlarına daha yakın hale geliyor. Eklentiler de kendilerine ait dosya işlemleri IJent üzerinden geçtiğinde bundan yararlanıyor.
IJent, JetBrains'in platform geliştiricileri ve eklenti yazarları açısından yerel ve uzak ortamlar arasındaki farkı gizlemek üzere tasarladığı EelApi ile bağlantılı çalışıyor. Bu modele göre aynı kod, her ortam için özel mantık eklenmesine gerek kalmadan yerel ortam, WSL, Docker veya Dev Container ile çalışabiliyor. Şirket, IJent'in EelApi'yi uyguladığını ve işlevlerini gerçek anlamda sağladığını söylüyor.
Testler ne söylüyor?
JetBrains, 23 alt proje ve 8.191 kaynak dosyası içeren spring-framework projesinin soğuk açılış testinde 9P mode ile IJent mode'u karşılaştırdı. Ölçümler Windows 11, WSL 2, Ubuntu 24.04 ve IntelliJ IDEA Ultimate 263.SNAPSHOT sürümü üzerinde yapıldı; sonuçlarda beş çalıştırmanın medyanı kullanıldı.
- Çalışmaya hazır olma: Süre 18,5 saniyeden 11,5 saniyeye indi; iyileşme oranı %38 oldu.
- Proje ağacını tarama: Süre 8,1 saniyeden 3,7 saniyeye indi; bu, %54 daha az süre anlamına geliyor.
- Dosyaları dizinleme: Süre 10,8 saniyeden 8,4 saniyeye indi; iyileşme %22 oldu.
- Dosya içeriklerini okuma: Süre 12,2 saniyeden 5,7 saniyeye indi; bu, %53 daha az süre anlamına geliyor.
Şirket, az sayıda dosya içeren küçük bir projenin aynı testte ölçülebilir bir fark göstermediği konusunda uyarıyor. Bu nedenle pratikteki en büyük kazanım, büyük projeler veya çok sayıda dosyaya erişimin tekrarlandığı iş akışları için geçerli.
Bu, geliştiriciler açısından ne anlama geliyor?
En önemli değişiklik, önceki tüm seçeneklerin hemen ortadan kaldırılması değil, önerilen giriş noktası ve mimarinin birleştirilmesi. Desteklenen ürünlerde bir WSL projesini doğrudan açan kullanıcı Native mode'u alırken Remote Development, bu yolu seçen veya istemci ile backend'in ayrıldığı modele ihtiyaç duyan kişiler için kullanılabilir olmaya devam ediyor. IDE'nin kendisini WSLg üzerinden çalıştırmaya gelince JetBrains, bunun teknik olarak mümkün olduğunu; ancak çizim, pencere yönetimi ve girişle ilgili kısıtlamalar ve uygulamanın Windows içindeki bir Linux görüntüleme katmanına bağımlılığı nedeniyle birinci sınıf olarak desteklenen bir iş akışı olmadığını söylüyor.
Yayımlanan sonuçlar bazı işlemlerde belirgin bir iyileşmeye işaret ediyor; ancak test kapsamı belirli bir proje, ortam ve sürümle sınırlı. Bu nedenle rakamlar tüm projeler veya eklentiler için sürekli bir üstünlüğü kanıtlamıyor. Ayrıca yeni mimarinin JetBrains'in daha fazla ürününe uygulanması hâlâ devam ediyor; bu da eklentilerin uyumluluğunu ve farklı ortamlardaki davranışını izlenmeye değer bir konu haline getiriyor.