Community
Participate
Working Groups
3.0 M7 build - UI in source, rest imported as binary - set breakpoint in Workbench.startPlugins on line: for (int i = 0; i < extensions.length; i++) { - debug target eclipse - breakpoint is hit - show Breakpoints view - Run > Toggle Breakpoint (or Ctrl+Shift+B) - the breakpoint is not removed, and the Breakpoints view indicates that a duplicate one has been created
Nothing of interest in either log.
Fixed. Was a side effect of bug 22610. When a breakpoint set in an anonymous or local class is installed in a java debug target, getTypeName return the compiled name of the class (with the extra $...). Checking if there is a breakpoint at the position was failing because the names doesn't match. Modified JDIDebugModel#lineBreakpointExists(..) to handle this case.
Please verify, Darin W.
Fixed compare ordering bug.
Name compare was in wrong oder. Please verify change to JDIDebugModel, Luc.
(fixed)
Errr ... no, my compare order was right, the breakpoint type name can be more precise (because having more information when installed) than the name of the type we want to compare to (which should be only a 'well-know' type name, not from a local or an anonymous type). My fix solved only the problem when the breakpoint is in a binary type, in source type, there was still some problem. I think that JDT became more precise on the elements they return from ICompilationUnit#getElementAt() and IClassFile#getElementAt(), and we are now getting local types when using this methods (I think that before, they were returning only return the non-local types in which the local type were define). The problem for us is the fact that they return names for this local type that are not garanty to the right one (see bug 53555).
Fixed the problem with source types. When getting the type where to set the breakpoint, it now check that it's not local type in a source type.
Verified
