Eclipse JDT Debug lets you define a "Detail Formatter" per type — a small expression (e.g. getName() + ": " + getId()) that's evaluated against instances of that type and shown in the Variables view, Expressions view, and on hover. It's saved per type and applies automatically across debug sessions, without editing code. IntelliJ IDEA has the same capability under "Type Renderers", so this is a common expectation for anyone moving between Java IDEs.
VS Code doesn't have this today. #236 requests it and is still open; the only workaround suggested there is typing the expression manually in the Watch panel each time, which doesn't persist and has to be redone per object/session.
Benefits: saves repeated manual Watch-panel entries for the same type across sessions, makes deeply nested or verbose objects (entities, DTOs, wrapper types) readable at a glance in Variables/hover, and closes a well-known parity gap for developers coming from Eclipse or IntelliJ.
java-debug already uses Eclipse's ASTEvaluationEngine (along with JDIThread/JDIStackFrame) for expression/watch evaluation, so the engine that evaluates an arbitrary snippet against a suspended object is already in place and can be further reused here. Eclipse's own formatter resolution logic in JavaDetailFormattersManager — can also be reused (some parts maybe), matching a formatter by walking up a type's superclass/interface hierarchy rather than requiring an exact type match, and caching the compiled expression per type per session instead of recompiling on every render.
Related to eclipse-jdtls/eclipse.jdt.ls#3834
Eclipse JDT Debug lets you define a "Detail Formatter" per type — a small expression (e.g. getName() + ": " + getId()) that's evaluated against instances of that type and shown in the Variables view, Expressions view, and on hover. It's saved per type and applies automatically across debug sessions, without editing code. IntelliJ IDEA has the same capability under "Type Renderers", so this is a common expectation for anyone moving between Java IDEs.
VS Code doesn't have this today. #236 requests it and is still open; the only workaround suggested there is typing the expression manually in the Watch panel each time, which doesn't persist and has to be redone per object/session.
Benefits: saves repeated manual Watch-panel entries for the same type across sessions, makes deeply nested or verbose objects (entities, DTOs, wrapper types) readable at a glance in Variables/hover, and closes a well-known parity gap for developers coming from Eclipse or IntelliJ.
java-debug already uses Eclipse's
ASTEvaluationEngine(along withJDIThread/JDIStackFrame) for expression/watch evaluation, so the engine that evaluates an arbitrary snippet against a suspended object is already in place and can be further reused here. Eclipse's own formatter resolution logic in JavaDetailFormattersManager — can also be reused (some parts maybe), matching a formatter by walking up a type's superclass/interface hierarchy rather than requiring an exact type match, and caching the compiled expression per type per session instead of recompiling on every render.Related to eclipse-jdtls/eclipse.jdt.ls#3834