Community
Participate
Working Groups
3.2 This feature request stems from bug 119860. The debugger allows expression evaluations, and although the debugger could allow access/sending messages to private inherited fields, we currently can't allow users to do this because the AST does not expose resolved bindings as needed. For example, consider the following classes, A & B: public class A { private String name = null; public A(String aName) { name = aName; } } import java.util.Vector; public class B extends A { public B(String name) { super(name); } public static void main(String[] args) { new B("SimpleTest").test(); } public void test() { Vector v = new Vector(); // BREAKPOINT for (int i = 0; i < 100; i++) { v.add(new Integer(i)); } } } * Place a breakpoint as indicated in B.test() * Debug to the breakpoint * evaluate the expression "this.name.length()" > error message "The field A.name is not visible" appears The underlying cause is that we do not have a method binding in our "evaluation snippet AST" for the method invocation node. I believe this is because the "name" node does not have a resolved type. If the AST could expose such bindings to us, then we could allow the expression evaluation to proceed. Place a breakpoint in ASTInstructionCompiler, line 2651 to inspect the relevant code. Also note that if I turn off the "hide forbidden references" in code assist options I can code assist the "this.name", but I do not get code assist completions for "this.name.length".
Indeed we don't report a binding for this.name.length(), but we do report a binding for this.name within this expression. When the receiver is not a valid binding, we don't preserve a binding for the method invocation. Philippe, is this one of the cases we want to improve?
Why do you expect a binding in this case? You get the error message saying that this.name is not visible. How would a binding help you to do anything?
The debugger can perform the evaluation at debug time even though the method is not visible at compile. The visibility check is performed by the compiler - not the runtime. It provides more flexible evaluation support.
But its not the method that is not visible - its the field (receiver) itself. I don't see how we could report the correct error if we kept resolving the rest of a compound expression. For example : a.b.c().d.e() What would we answer if the field b or d is not visible? I don't see how we could answer the method c() or e().
The debugger also has access to private fields.
As long as the compiler doesn't expose the bindings in this case for the method invocation, nothing can be done for DOM/AST bindings.
Created attachment 49759 [details] Regression test To keep a regression test for this bug.
This works in HEAD. Closing as WORKSFORME.
Created attachment 154130 [details] Proposed fix to re-enable the regression test
(In reply to comment #8) > This works in HEAD. > Closing as WORKSFORME. Hello Olivier, If by saying "This works in HEAD", you meant special allowances have been made for the debugger's sake so some expressions which would result in error at compile time could still be evaluated at debug time, that doesn't seem to be the case. On HEAD if I attempt to evaluate the expression this.name.length() at the point suggested in comment#0 I still see the same error. I can see that the regression test that has been enabled now passes, but there is some disconnect here ? what is the regression test establishing to be the case is not sure. I'll wait for your comments before changing status to VERIFIED or REOPENED as the case may be.
Reopen as the original problem is not fixed. The "regression" test needs to be reviewed as well.
Darin, could you please have a look? We do return a binding for this.name now, but we still report the error: [Pb(71) The field A.name is not visible] I think this makes sense. The binding is pointing to the private field defined in the superclass.
Moving to JDT/Debug for investigation.
The field binding is present, but the method binding is not, so the debugger fails to be able to send the message length() to the field. Not sure if there are any options JDT exposes to allow binding resolution to proceed even though there are visibility issues?
(In reply to comment #14) > The field binding is present, but the method binding is not, so the debugger > fails to be able to send the message length() to the field. Not sure if there > are any options JDT exposes to allow binding resolution to proceed even though > there are visibility issues? Are you talking about the binding for the length() method ?
(In reply to comment #15) > (In reply to comment #14) > > The field binding is present, but the method binding is not, so the debugger > > fails to be able to send the message length() to the field. Not sure if there > > are any options JDT exposes to allow binding resolution to proceed even though > > there are visibility issues? > Are you talking about the binding for the length() method ? Yes.
Created attachment 159606 [details] Proposed fix Current patch under testing.
The proposed patch enables the debugger to send messages to non-visible members. Moving back to JDT core.
Created attachment 159611 [details] Proposed fix + regression tests New patch adjusting existing tests.
Released for 3.6M6. Updated existing regression test.
Verified for 3.6M6 using build I20100305-1011
