fix: avoid spurious 'restart terminal' prompts on every window reload

[wenytang-ms]

Summary

Fixes #1647: the Debugger for Java extension prompts the user to restart their terminal every time the VS Code window is reloaded, even when nothing about the contributed environment has actually changed.

Root cause

• "src/noConfigDebugInit.ts" + runs on every activation and unconditionally:

1. Calls + "collection.clear()" + on + "context.environmentVariableCollection" + .
2. Re-adds + "VSCODE_JDWP_ADAPTER_ENDPOINTS" + , + "VSCODE_JAVA_EXEC" + , and a + "PATH" + append.

• "EnvironmentVariableCollection" + is persistent ( + "persistent = true" + ) and VS Code triggers the restart terminal prompt whenever the collection differs from what was last applied to running terminals. clear() followed by a re-add is always interpreted as a change, even when the resulting set of variables is byte-identical, so the prompt fires on every reload (see Clearing an environment variable causes relaunch terminal button to get stuck vscode#95919, Ability to clear/delete a variable inside EnvironmentVariableCollection when extension is disposed/restarted vscode#234384).

Fix

Introduce diff-aware helpers in src/envVarSync.ts:

• applyReplaceIfChanged / applyAppendIfChanged — only call replace / append when the existing mutator's type, value, and normalized options differ from the desired ones.
• deleteIfPresent — only call delete when a mutator exists.

Rewrite the activation flow in src/noConfigDebugInit.ts to use those helpers and drop the unconditional clear(). On a typical reload all comparisons are no-ops, so VS Code never observes a change and never prompts.

Behavioral notes

• Java executable detection failures no longer wipe VSCODE_JAVA_EXEC. If getJavaHome() returns nothing (e.g., JDT LS hasn't finished initializing), we keep the previously stored value instead of deleting it, avoiding churn from transient startup hiccups.
• One-time legacy cleanup: explicitly delete keys older versions used to set but no longer manage (currently just JAVA_TOOL_OPTIONS, per the comment that was already in this file). After the first reload this is also a no-op.
• Description: set collection.description = Java No-Config Debug`` so the source is visible in VS Code's environment-variable UI.

Tests

Added test/envVarSync.test.ts with 13 cases covering:

• write-on-missing, no-op-on-match, write-on-value-diff, write-on-options-diff
• override across mutator types (Replace ↔ Append)
• deleteIfPresent present/absent
• a regression test simulating two back-to-back activations and asserting the second one performs zero writes — this is the exact scenario from Extension keeps requesting to restart my terminal #1647.

Full npm test output: 24 passing, 0 failing.

Risk

• Scope is limited to the No-Config Debug activation path.
• No public API surface changes; registerNoConfigDebug signature unchanged.
• One-time prompt may still appear after upgrading to a version whose extPath differs (the PATH append value embeds the extension version directory) — this is unavoidable and only happens once per upgrade.

[Copilot]

Pull request overview

This PR fixes #1647 by making the extension’s persistent EnvironmentVariableCollection updates idempotent, so VS Code doesn’t interpret every window reload as an environment change that requires restarting terminals.

Changes:

• Added diff-aware helpers (applyReplaceIfChanged, applyAppendIfChanged, deleteIfPresent) to avoid writing to the environment collection when nothing effectively changes.
• Updated no-config debug activation to stop calling collection.clear(), perform one-time legacy cleanup, and set a visible collection description.
• Added unit tests covering mutator diffing behavior and a regression test for back-to-back activations.

Reviewed changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated no comments.

File	Description
src/envVarSync.ts	Introduces idempotent environment-variable collection update helpers with option normalization.
src/noConfigDebugInit.ts	Switches activation flow to diff-aware updates (no clear()), adds legacy cleanup + collection description.
test/envVarSync.test.ts	Adds targeted unit/regression coverage ensuring repeated activations produce zero writes when unchanged.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[wenytang-ms]

Good catch — agreed, removed in bf7fff1.

To clarify why it was safe but still worth removing:

• context.environmentVariableCollection is per-extension. collection.delete() only removes a mutator that this extension previously wrote; it can never touch a JAVA_TOOL_OPTIONS the user set in their shell profile, settings.json terminal.integrated.env.*, or another extension's collection.
• I checked the history with git log -S JAVA_TOOL_OPTIONS -- src/noConfigDebugInit.ts — this extension has never called collection.replace('JAVA_TOOL_OPTIONS', ...). The only reference is the comment from feat: no config debug #1578 explaining why we deliberately don't set it. So the cleanup loop was dead code.

Since the value was effectively zero and the code reads as if it might be doing something risky, dropping it is the cleaner call. PR updated.