Community
Participate
Working Groups
Build Identifier: N20100620-2000 While debugging a class like the following: class Scratch { public static void main(String [] args) { final String hi = new String("hi"); new Object() { public void foo() { System.out.println(hi); // BREAKPOINT } }.foo(); } } If you stop on the line marked BREAKPOINT, i.e. your stack frame is Scratch$1.foo(), you can't mouseover the "hi" variable, and you can't perform evaluations on inspections on or including it directly. It is visible in the Variables view under "this". The hover just gets you the type. ("String hi - Main.main(String[])"). Evaluating (ctrl+shift+d ctrl+shift+i ctrl+shift+u) claim "Error Evaulating: hi cannot be resolved to a variable". (note: new String() is required to make hi not a 15.28 constant, which does work) Reproducible: Always Steps to Reproduce: 1. Open the above class in an editor. 2. Breakpoint the indicated line. 3. Debug. 4. Attempt to get information about the hi local variable.
Created attachment 172466 [details] Proof of concept fix inside JDIStackFrame/JDILocalVariable Hacked-up proof-of-concept implementation. Mostly untested apart from the case in the bug report. Small discussion on JavaDebugHover. Hover occasionally (and unreproducably) reverts to old behaviour.
This is a dup of good old bug 45507. The suggested fix is to display/reveal the field as a local in the method - which isn't correct in terms of the Java language structure/spec. The variable is really a field of the receiver. I'd rather see a fix for the ASTEvalautionEngine that could resolve such variables. For hover, we'd also need some way to identify them. But I don't think we should pollute local variables with non-locals. *** This bug has been marked as a duplicate of bug 45507 ***