Remote Java Debugging

Problem

Debugging a remote Java process often needs a lightweight entry point that stays close to the source tree. You must connect to a JDWP-enabled JVM, set breakpoints by class, line, or method, and inspect the hit context: local variables, object fields, and call stack. When the target class lacks -g:vars, method parameters may appear as arg0, making root-cause analysis harder.

How It Works

The skill runs against a source workspace, defaulting to the current directory. It connects to a remote JVM through a local debug service and supports:

• Breakpoints: by class and line, source path and line, method name, or overloaded method; simple conditions can be attached.
• Context inspection: threads, current stack, current variables, and deeper object fields via fields.
• Object display: first-level object fields are expanded, String values resolved, wrappers unboxed, and common collections rendered.
• Stepping: step over, step into, and step out to follow execution and return values.
• Parameter recovery: when LocalVariableTable is missing, it attempts to recover method parameter names from source.

Boundaries

The remote JVM must expose a JDWP debug port, and the workspace should map to the project source root. Target classes must be loaded before breakpoints can be set. A hit suspends the thread, so you must continue or step. Method breakpoints depend on line-number info, and conditional breakpoints work best with simple comparisons. If source and runtime versions differ, recovered names may be inaccurate, and all local variable names are not guaranteed.