Community
Participate
Working Groups
Suppose I have the following statement: IUpdateSiteAdapter mapped = ProductRegistry.getUpdatePolicy().getMappedSite(getIdentifier ()); If I double click on the first line, I expect a breakpoint to be set at the first effective instruction of the statement. However, the breakpoint gets set on the instruction that corresponds to the assignment -- which is after the invocations to "getUpdatePolicy", "getMappedSite", etc. I can only set a breakpoint on the first effective instruction by double-clicking on the second line of the statement. This is very counter-intuitive. I've never worked with a debugger that works like this.
*** This bug has been marked as a duplicate of 75599 ***
It's not a dup. In this case, the user add the breakpoint on the first line of the expression. In bug 75599, the user ask for the breakpoint on line of the method declaration.
OK, so in bug 75599, the breakpoint should be a method entry breakpoint. However, in this bug, my understanding was that the breakpoint appears on the line with the "=", which means the breakpoint is on the entire statement starting on that line. Execution should stop before the calls to getUpdatePolicy() and getMappedSite() - if it is not, then there is a bug.
When I use an example statement as follows, with a breakpoint on the assignment line, execution stops at the line, and performing "step into's" I see the correct execution order - first a "new Vector(), then "v.toString()", then "new StringBuffer(String)"... boolean a = new Vector().add( new StringBuffer( v.toString()) ); I think this is working as expected.
However, if I use static methods, then I see the same (wrong) behavior: boolean a = Boolean.getBoolean( new StringBuffer("true").toString()); In this case, execution does not step into the methods. Needs investigation.
This is not a problem of instance or static method, but a problem with split assigment to local variable, and split local variable declaration with initializer. It's more a result of how Java works than anybody's bug. In Java, a breakpoint is set on a line, and the VM stops its execution just before executing the code associated to the specified line. In this case, with the code generated by the Eclipse Java compiler, the first piece of code associated with the first line of the assigment, is the code which stores the result of the right-hand expression in the local variable. This code is executed after the evaluation of the right-hand expression, so when the breakpoint is hit, the methods "getUpdatePolicy" and "getMappedSite" have already been executed. This behavior is only visible if the variable is a local variable. In the other cases, there will be a piece of code, associated to the first line of the assigment, to resolve the variable. This code is executed before the evaluation of the right-hand expression, so when breakpoint would be hit before the execution of the methods "getUpdatePolicy" and "getMappedSite". One solution would be to add some bytecode before the evaluation of the right-hand expression (nop ?), associated to the first line of the evaluation. But it's ugly. Moving to JDT/Core to comment/close.
*** Bug 82269 has been marked as a duplicate of this bug. ***
Forgot to add that the problem cannot be reproduced if the class in compiled with javac. It generates way less precise debug information. Even if a statement is split on multiple lines, it sets the first line of the statement as the location for all the code of the statement.
Will consider post 3.2
As of now 'LATER' and 'REMIND' resolutions are no longer supported. Please reopen this bug if it is still valid for you.
