Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 317643

Summary: Variables from parent scope aren't available during evaluations in inner classes
Product: [Eclipse Project] JDT Reporter: Chris West (Faux) <eclipse>
Component: DebugAssignee: JDT-Debug-Inbox <jdt-debug-inbox>
Status: CLOSED DUPLICATE QA Contact:
Severity: normal    
Priority: P3 CC: darin.eclipse
Version: 3.6   
Target Milestone: ---   
Hardware: PC   
OS: Windows Vista   
Whiteboard:
Attachments:
Description Flags
Proof of concept fix inside JDIStackFrame/JDILocalVariable none

Description Chris West (Faux) CLA 2010-06-22 17:40:57 EDT
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.
Comment 1 Chris West (Faux) CLA 2010-06-22 17:43:32 EDT
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.
Comment 2 Darin Wright CLA 2010-06-23 14:59:58 EDT
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 ***