Debugger for Java impede a criação do launch.json e trava a configuração de depuração

[elvisondev]

Etapas para reproduzir

1. Abra o VS Code com a extensão "Debugger for Java" habilitada.
2. Abra uma pasta de projeto Node.js/TypeScript.
3. Acesse a área "Executar e Depurar".
4. Clique em "crie um arquivo launch.json" ou execute o comando "Debug: Add Configuration...".
5. O VS Code fica preso em "Ativando Extensões..." e o arquivo launch.json não é criado.
6. Em alguns momentos também aparece uma notificação solicitando a instalação de um JDK, mesmo o projeto atual sendo Node.js/TypeScript.

Comportamento esperado

O VS Code deveria exibir as configurações de depuração disponíveis, permitir selecionar Node.js e criar normalmente o arquivo .vscode/launch.json.

Comportamento atual

A configuração de depuração não é carregada e o VS Code permanece em "Ativando Extensões...".

Resultado da Bifurcação de Extensão

Executei a ferramenta "Extension Bisect" do VS Code para identificar a extensão responsável.

Durante os testes, o problema desapareceu quando determinadas extensões foram desabilitadas e voltou quando a extensão problemática foi habilitada.

Ao final do processo, o Extension Bisect identificou:

vscjava.vscode-java-debug

(Debugger for Java)

como a extensão responsável pelo problema.

Após manter a extensão "Debugger for Java" desabilitada, a criação do launch.json e a seleção das configurações de depuração do Node.js voltaram a funcionar normalmente.

[issuelens]

Obrigado pelo relato detalhado e pelo teste com o Extension Bisect. O bloqueio da criação do launch.json em um projeto Node.js/TypeScript, que desaparece ao desabilitar o Debugger for Java, é um indício importante de falha na ativação da extensão.

No código atual, a extensão pode ser ativada ao solicitar configurações iniciais de depuração, mesmo sem abrir um arquivo Java. Durante essa ativação, a inicialização do recurso Java No-Config Debug aguarda a obtenção do ambiente Java, que pode ativar o redhat.java (ativação, inicialização, consulta ao ambiente Java). Esse caminho é compatível com o sintoma, mas ainda precisamos confirmar onde a espera ocorre na sua instalação; o Bisect não identifica sozinho a causa exata.

Como alternativa temporária, mantenha o Debugger for Java desabilitado apenas neste workspace Node.js/TypeScript, já que isso resolveu o problema no seu teste. Para ajudar a isolar a falha, se a opção estiver disponível na sua versão, teste também com a extensão habilitada e "java.debug.settings.enableNoConfigDebug": false nas configurações do workspace, seguido de Developer: Reload Window. Esse é um teste de diagnóstico, não uma correção confirmada.

Pode informar:

• versões do VS Code, Debugger for Java e Language Support for Java (redhat.java), sistema operacional e se usa WSL, SSH ou Dev Container;
• se o teste acima permite criar o launch.json e se o problema também ocorre em uma pasta mínima contendo apenas package.json e um arquivo .ts;
• o texto exato da notificação sobre o JDK e os erros de Output → Log (Extension Host) e dos canais Java disponíveis, capturados logo após reproduzir o bloqueio? Remova caminhos pessoais, tokens e outros dados sensíveis antes de compartilhar.

[wenytang-ms]

Workaround enquanto a correção não é publicada: desabilite o Debugger for Java somente neste workspace Node.js/TypeScript.

1. Abra Extensões, localize Debugger for Java (vscjava.vscode-java-debug) e use a engrenagem → Disable (Workspace) / Desabilitar (Workspace).
2. Execute Developer: Reload Window.
3. Tente criar o launch.json novamente e selecione o depurador Node.js.

Isso mantém a extensão habilitada nos outros workspaces. Não é necessário instalar um JDK para depurar um projeto Node.js/TypeScript. É a alternativa que já funcionou no seu teste, aplicada apenas a este workspace.

Uma observação sobre a sugestão anterior: java.debug.settings.enableNoConfigDebug ainda não existe na release 0.59.0. Além disso, identificamos outro caminho de ativação, na integração de links de stack trace, que não é controlado por essa opção. Por isso, Disable (Workspace) é o workaround mais seguro aqui.

Abri a correção em #1704. Ela remove a ativação desnecessária de Java tanto da preparação do No-Config Debug quanto dos links de stack trace, e corrige a propagação de erros de ativação que poderiam deixar uma Promise pendente indefinidamente. As integrações continuam disponíveis se Java for ativado posteriormente no mesmo workspace.

O PR ainda está em revisão e não foi publicado. A correção cobre esses caminhos identificados no código; o ponto exato da falha na sua instalação ainda não foi confirmado pelos logs.