A partir da versão 2026.2, abrir um projeto existente no Windows Subsystem for Linux, ou WSL, pelo IntelliJ IDEA, WebStorm e PhpStorm leva ao que a JetBrains chama de modo Native. Nesse modo, o IDE continua sendo um aplicativo executado no Windows, enquanto um pequeno agente dentro do WSL executa operações de arquivos e processos de software em seu nome. A empresa afirma que essa é atualmente a entrada recomendada, enquanto a opção Remote Development continua disponível na tela de boas-vindas, mas deixou de ser a forma preferida de abrir projetos WSL.
A questão não envolve apenas uma mudança de nome na interface do usuário. O suporte a um projeto Linux existente dentro do WSL exige que o ambiente de desenvolvimento acesse arquivos, execute ferramentas com os caminhos corretos, gerencie variáveis de ambiente e execute processos de compilação, depuração e criação de perfis, mantendo a latência baixa o suficiente para que a experiência pareça natural. A JetBrains explica que os métodos anteriores usavam arquiteturas diferentes dependendo do ponto de entrada, o que causava variações de desempenho e comportamento entre produtos e cenários.
Por que o caminho 9P deixou de ser suficiente?
Na abordagem mais antiga, os aplicativos da JetBrains no Windows acessavam arquivos do WSL pelo protocolo de sistema de arquivos 9P, enquanto a classe GeneralCommandLine cuidava da normalização dos comandos executados no ambiente Linux. Isso permitia executar o IDE em projetos WSL, mas transferia grande parte das operações de leitura e indexação através da fronteira entre o Windows e a máquina virtual que hospeda o WSL.
Segundo a JetBrains, surgiram três problemas principais. Primeiro, o 9P não exibe corretamente os links simbólicos do Linux pelo caminho \\wsl$, o que pode impedir o IDE de resolver ou indexar algumas árvores. Esse problema afeta ambientes que usam links simbólicos, como espaços de trabalho do pnpm, ambientes virtuais do Python e repositórios do Composer baseados em caminhos. Segundo, a verificação do Microsoft Defender durante o acesso pode prolongar a leitura de arquivos do WSL em dezenas de segundos. Terceiro, o protocolo acrescenta um tempo significativo às operações que lidam com um grande número de arquivos pequenos, como a indexação.
A camada de execução de comandos também obrigou os desenvolvedores da plataforma a lidar com semânticas específicas do WSL em diferentes partes da base de código. A JetBrains considera que isso tornou a abordagem mais difícil de ampliar e manter, em vez de servir como uma base unificada para ambientes de trabalho não locais.
O que o Remote Development acrescentou?
O Remote Development resolveu o problema na direção oposta: o backend completo do IDE é transferido para o WSL, enquanto no Windows permanece um cliente que exibe a interface e recebe as entradas do usuário. As duas partes se comunicam pelo protocolo JetBrains RD, que transporta modelos de eventos e o estado do editor e do projeto em ambas as direções. Já as operações pesadas, como indexação, análise, compilação, depuração e operações de controle de versão, ocorrem dentro do WSL, próximas aos arquivos.
Esse design eliminou a dependência direta do 9P para acessar arquivos, mas acrescentou outro custo. A JetBrains afirma que o backend requer cerca de 2 gigabytes adicionais de espaço em disco, além do tempo para baixá-lo e instalá-lo dentro do WSL. A interação contínua entre o cliente e o backend também impõe uma movimentação constante do estado da interface e das entradas do usuário, o que pode afetar a responsividade. O desenvolvimento do próprio produto exige separar partes do código entre cliente e servidor, o que pode causar atrasos ou congelamentos em interfaces dinâmicas se alguns módulos permanecerem não divididos.
Como funciona o Native mode?
A nova abordagem depende de um agente chamado IJent. O agente executa operações de arquivos e processos dentro do ambiente-alvo, em vez de encaminhá-las pelo 9P ou por camadas gerais de execução. A JetBrains o descreve como um componente pequeno escrito em Rust, reduzindo a necessidade de dependências adicionais de execução, como Java ou Kotlin, dentro do WSL ou dos contêineres.
O IJent usa uma camada de transporte baseada em Stdio, que é portável e não exige a abertura de portas de firewall, enquanto os Hyper-V sockets no WSL oferecem um caminho mais rápido, especialmente ao transferir grandes quantidades de arquivos. Como as operações do sistema de arquivos são executadas dentro do próprio ambiente Linux, o tratamento de caminhos e links simbólicos fica mais próximo da semântica nativa do Linux. As extensões externas também se beneficiam disso quando suas operações de arquivos passam pelo IJent.
O IJent está associado à EelApi, uma interface criada pela JetBrains para ocultar a diferença entre ambientes locais e remotos diante dos desenvolvedores da plataforma e dos autores de extensões. Segundo esse modelo, o mesmo código pode lidar com um ambiente local, WSL, Docker ou Dev Container sem adicionar lógica específica para cada ambiente. A empresa afirma que o IJent implementa a interface EelApi e fornece suas funções reais.
O que dizem os testes?
A JetBrains comparou os modos 9P e IJent em um teste de abertura a frio do projeto spring-framework, que inclui 23 subprojetos e 8,191 arquivos de origem. As medições foram realizadas no Windows 11 com WSL 2, Ubuntu 24.04 e a versão IntelliJ IDEA Ultimate 263.SNAPSHOT, usando como resultado a mediana de cinco execuções.
- Pronto para trabalhar: o tempo caiu de 18.5 segundos para 11.5 segundos, uma melhoria de 38%.
- Verificação da árvore do projeto: caiu de 8.1 segundos para 3.7 segundos, ou 54% menos.
- Indexação de arquivos: caiu de 10.8 segundos para 8.4 segundos, uma melhoria de 22%.
- Leitura do conteúdo dos arquivos: caiu de 12.2 segundos para 5.7 segundos, ou 53% menos.
A empresa alerta que um projeto pequeno com poucos arquivos não apresentou uma diferença mensurável no mesmo teste. Portanto, o maior ganho prático diz respeito a projetos grandes ou a fluxos de trabalho nos quais o acesso a um grande número de arquivos se repete.
O que isso significa para os desenvolvedores?
A mudança mais importante é a unificação do ponto de entrada e da arquitetura recomendada, não a eliminação imediata de todas as opções anteriores. O usuário que abre diretamente um projeto WSL nos produtos compatíveis obtém o Native mode, enquanto o Remote Development continua sendo útil para quem escolhe esse caminho ou precisa do modelo separado de cliente e backend. Quanto à execução do próprio IDE pelo WSLg, a JetBrains afirma que isso é tecnicamente possível, mas não constitui um fluxo de trabalho compatível de primeira linha, devido a limitações relacionadas a gráficos, gerenciamento de janelas e entrada, além da dependência do aplicativo de uma camada de exibição Linux dentro do Windows.
Os resultados publicados indicam uma melhoria perceptível em algumas operações, mas o escopo do teste é limitado a um projeto, um ambiente e uma versão específicos. Portanto, os números não comprovam uma superioridade constante para todos os projetos ou extensões. Além disso, a adoção da nova arquitetura em mais produtos da JetBrains ainda está em andamento, o que torna a compatibilidade e o comportamento das extensões em diferentes ambientes um ponto que merece acompanhamento.