Repository navigation
Java Debug Server
microsoft/java-debug implements server-side Java debugging. The page distinguishes that server from the VS Code debugger extension: this component exposes JDT Language Server (JDTLS) delegate commands and runs the protocol server; it does not describe VS Code debug UI or launch.json editing.
The plugin contributes JavaDebugDelegateCommandHandler to JDTLS's org.eclipse.jdt.ls.core.delegateCommandHandler extension point. Its registered commands include starting a debug session, resolving classpaths and main classes, validating launch configuration, updating debug settings, and resolving source/class-filter information. The handler starts the singleton JavaDebugServer for vscode.java.startDebugSession and returns its port; the other commands are handled by the server-side delegate implementations.
JavaDebugServer creates a server socket, accepts connections, and creates a ProtocolServer for each connection with a JDT-backed provider context. ProtocolServer creates a DebugAdapter and dispatches protocol requests through it. DebugAdapter registers common initialization/launch handlers and debug-mode handlers for attach, breakpoints, stepping, stack/scopes/variables, evaluation, hot-code replace, completions, exception information, data breakpoints, and related requests; its no-debug mode has a narrower handler set.
The checked-in Queue IssueLens Team Memory (opt-in) workflow triggers only on pushes to main. Its team-memory job requires ISSUELENS_TEAM_MEMORY_ENABLED == 'true', repository microsoft/java-debug, a ref matching the repository's current default branch, a push event, github.workflow_sha == github.sha, and false created, deleted, and forced flags. The explicit main trigger does not automatically follow a default-branch rename. The job runs on ubuntu-latest with a 10-minute timeout; workflow-level permissions are empty, with no job-level permissions override. [Workflow evidence below.]
Dispatch authentication uses actions/create-github-app-token@bcd2ba49218906704ab6c1aa796996da409d3eb1 (v3.2.0), reading vars.ISSUELENS_DISPATCH_APP_CLIENT_ID and secrets.ISSUELENS_DISPATCH_APP_PRIVATE_KEY. It scopes the requested token to owner microsoft, repository vscode-java-pack, with Contents-read and Actions-write permissions. The queue step receives steps.dispatch-token.outputs.token, not github.token. PR #640 restores this App-token wiring and removes the source-job Contents-read/Actions-write override introduced by #639. Its stated rationale is that source-repository GITHUB_TOKEN permissions do not grant cross-repository Actions-write access. The checked-in references establish configuration dependencies, not that variables, secrets, or App access have been configured.
The queue step invokes microsoft/IssueLens/.github/actions/queue-team-memory@a81d2d96167fc0e69ac631c2edc85f858e693289, targeting microsoft/vscode-java-pack, workflow team-memory-coordinator.yml, ref main. Its JSON input contains exactly five string fields: source_repository (github.repository), source_run_id (github.run_id), source_run_attempt (github.run_attempt), push_before (github.event.before), and push_after (github.sha). This source workflow contains neither workflow_dispatch nor a concurrency declaration or direct agent invocation. See Java Pack's coordinator and manual-recovery documentation for the separately documented coordinator boundary; its implementation was not revalidated here.
Workflow evidence: microsoft/java-debug/.github/workflows/team-memory-post-merge.yml, on, permissions, and jobs.team-memory, verified at merged/source-tip commit 6a597f2bcccdd0aac7e91631588361826fde11f3; PR #640, source identity microsoft/java-debug#640:6a597f2bcccdd0aac7e91631588361826fde11f3. The complete one-file PR patch was inspected and PR identities rechecked after paging. This records final caller configuration and the authentication reversal, not shared-action internals, executed tests, successful token minting/dispatch, delivery guarantees, release, or deployment.
Historical provenance: the former Update IssueLens Team Memory configuration documented from PR #637, source identity microsoft/java-debug#637:1ed7ca84d30808adb5510dbdb406d88a8a99c858, used source-local manual PR dispatch, per-push/per-PR concurrency, a 30-minute timeout, and direct issuelens invocation. Its workflow at full source commit 1ed7ca84d30808adb5510dbdb406d88a8a99c858 is retained as superseded evidence, not current operation.
This component entry was added while onboarding microsoft/java-debug after PR #635. The behavior above was verified against source commit 7a625c6ff35f95e92ce232fcf6f0af64b9ce715b:
-
com.microsoft.java.debug.plugin/plugin.xml— JDTLS delegate-command contribution and command IDs. -
JavaDebugDelegateCommandHandler— command routing and debug-server startup. -
JavaDebugServer— socket listener, per-connection protocol server, and JDT provider context. -
ProtocolServerandDebugAdapter— protocol dispatch and handler registration.
ResolveMainClassHandler.resolveMainClassUnderPaths includes Java projects whose descriptions live outside the requested folder when their linked sources are inside it. For a nonempty folder filter, projects must still have a non-null project location and an existing Java project. Scope selection accepts containment of the project location, the invisible project's workspace-link folder, or a source-folder location. hasSourceFolderContainedIn examines raw-classpath CPE_SOURCE entries, resolves each workspace path with ResourcesPlugin.getWorkspace().getRoot().findMember, and checks the resource's non-null filesystem location. The search remains source-only.
Scope inclusion does not automatically accept every main class from a project with linked source roots in several workspace folders. In acceptSearchMatch, the existing project-location and invisible-project checks remain; otherwise isMatchContainedIn requires the match resource's location to be inside the requested paths. Thus matches admitted only through the new source-folder route are filtered by their own location, while asking with a project's own location retains the existing project-wide acceptance behavior. An empty path filter remains unrestricted across Java projects.
For diagnosis of missing folder-scoped main classes, distinguish the project location from linked source locations and the individual match location. If reading the raw classpath throws JavaModelException, the source-folder helper logs a warning beginning Failed to read the classpath of project and returns false. This is server-side resolution behavior, not a change to VS Code UI or project import ownership.
Evidence: microsoft/java-debug/com.microsoft.java.debug.plugin/src/main/java/com/microsoft/java/debug/plugin/internal/ResolveMainClassHandler.java, symbols resolveMainClassUnderPaths, acceptSearchMatch, hasSourceFolderContainedIn, isMatchContainedIn, and isContainedInInvisibleProject; verified at merged source commit bcae605a6240f11b447163a614e215721c11b107 (PR #633; source identity microsoft/java-debug#633:bcae605a6240f11b447163a614e215721c11b107). This revision is also the batch's push_after and supplied source_tip_sha. The complete PR changes only this implementation file, with no test changes. These findings are source-inspected, not a claim of executed tests, release availability, or deployment.