Community
Participate
Working Groups
Created attachment 93003 [details] Capute Build ID: Eclipse Europa Steps To Reproduce: 1. Define a class inside a method., 2. Put a breakpoint inside a method of this new inner class. 3. If I try to remove the breakpoint (clicking again), another breakpoint is added. I must remove the breakpoints in the "breakpoint" view. More information:
Created attachment 93005 [details] Example Java File
This is very annoying. :|
I20090605-1444 It's only a problem for local classes, but not for other inner classes (anonymous and member classes). In the example below, it's only a problem for breakpoint 1, and only when the class is being debugged. Steps with snippet below: - terminate all debug targets - doubleclick in gutter of line //breakpoint 1 => breakpoint created: Snippet$EnterListener [line: 18] - mouseEnter(MouseEvent) - doubleclicking again toggles breakpoint as expected - debug snippet - doubleclick in gutter of line //breakpoint 1 => different breakpoint created (additional $1 in name): Snippet$1$EnterListener [line: 18] - mouseEnter(MouseEvent) - each additional doubleclick adds another copy of the breakpoint package snippet; import org.eclipse.swt.*; import org.eclipse.swt.events.*; import org.eclipse.swt.layout.*; import org.eclipse.swt.widgets.*; public class Snippet { public static void main(String[] args) { Display display= new Display(); final Shell shell= new Shell(display); shell.setLayout(new FillLayout()); final Text text= new Text(shell, SWT.MULTI); class EnterListener extends MouseTrackAdapter { public void mouseEnter(MouseEvent e) { String msg= e.toString() + '\n'; // breakpoint 1 text.append(msg); } } text.addMouseTrackListener(new EnterListener()); text.addMouseTrackListener(new MouseTrackAdapter() { public void mouseExit(MouseEvent e) { String msg= e.toString() + '\n'; // breakpoint 2 (OK) text.append(msg); } }); text.addMouseTrackListener(new Snippet().new HoverListener(text)); shell.setSize(640, 480); shell.open(); while (!shell.isDisposed()) if (!display.readAndDispatch()) display.sleep(); shell.dispose(); } class HoverListener extends MouseTrackAdapter { private final Text fText; public HoverListener(Text text) { fText= text; } public void mouseHover(MouseEvent e) { String msg= e.toString() + '\n'; // breakpoint 3 (OK) fText.append(msg); } } }
While the problem occurs for me in other cases too, I _can_ reproduce the problem from Markus's comment 3. It seems that for whatever reasons, the name retrieved from ReferenceTypeImpl includes extra character(s). See ReferenceTypeImpl's nestedTypes() method.
Please consider fixing/investigating for 3.6. ;_;
(In reply to comment #5) > Please consider fixing/investigating for 3.6. ;_; This should be somewhat easy to fix, as we have code in API tools to resolve a similar issue for the placement of error markers. Handling local types is always somewhat tricky...
I20090917-0100 other weirdness: put a brekapoint on the final Text text= new Text(shell, SWT.MULTI); line from Markus' example and debug the snippet. When the snippet suspends, create a breakpoint at the //breakpoint 1 location. Breakpoint Snippet$EnterListener [line: 18] - mouseEnter(MouseEvent) is created (OK). Then press F8 and watch as the breakpoint is changed to be Snippet$1EnterListener [line: 18] - mouseEnter(MouseEvent)
(In reply to comment #7) > I20090917-0100 > > other weirdness: The problems are coming from when we respond to the classload event for Snippet$EnterListener to make sure the breakpoint is installed correctly. We end up setting the type name for the breakpoint to be Snippet$1EnterListener which is what ReferenceType tells us the name is (which differs from what the AST tells us when we create the breakpoint). Now if you try to remove the breakpoint (while debuging) we compare the type name in the breakpoint (Snippet$1$EnterListener) to the one we get from the AST (Snippet$EnterListener) and POOF you get a new breakpoint, as we think there is not one there for Snippet$EnterListener. Investigating a fix...
Hit a bit of a snag. It seems that when reconciling the compilation unit we are not getting back an AST that has bindings resolved. Speaking with Olivier he feels we should be getting bindings in the AST from a call to: CompilationUnit cunit = unit.reconcile(AST.JLS3, true, true, unit.getOwner(), null); Markus, can we ever expect to get bindings in the AST returned like this?
Snippet$EnterListener is computed inside org.eclipse.jdt.internal.debug.ui.actions.ToggleBreakpointAdapter.createQualifiedTypeName(IType). So this has nothing to do with the type qualified name we could return from the model. However in this case, the type qualified name doesn't insert a occurrence count into the type name. In your case, what you really want is the "resolved" name for the local type. i.e. Snippet$1EnterListener for >= 1.5 Snippet$1$EnterListener for < 1.5.
(In reply to comment #10) > Snippet$EnterListener is computed inside > org.eclipse.jdt.internal.debug.ui.actions.ToggleBreakpointAdapter.createQualifiedTypeName(IType). > So this has nothing to do with the type qualified name we could return from the > model. This is correct, but I was investigating moving away from having to piece together our own names - as it is error prone in uncommon cases.
(In reply to comment #9) > CompilationUnit cunit = unit.reconcile(AST.JLS3, true, true, unit.getOwner(), > null); > > Markus, can we ever expect to get bindings in the AST returned like this? Yes, I would expect you to get bindings in that AST. But I think a better solution would be for you to get the AST via SharedASTProvider.getAST(cu, SharedASTProvider.WAIT_YES, progressMonitor). As for the generated class name, I guess ITypeBinding#getBinaryName() is your friend (should work for local types from source and binary, with and without source attachments).
Created attachment 148040 [details] proposed fix The patch converts our toggle breakpoint adapter to use the ITypeBindings to get qualified names instead of trying to compose them ourselves. If for whatever reason bindings cannot be resolved we revert to the old method of composing type names. The patch also updates our breakpoint location verifier and our breakpoint marker updater to use bindings. I also found that when toggling a line breakpoint from the editor, we were running our location verifier twice and getting the qualified name twice, with the net effect of creating an AST 4 times. Location tests have been updated, all tests pass.
Created attachment 148055 [details] updated fix further testing of the proposed fix I found that importing breakpoints on local types was totally hosed as well, so this patch contains a fix for that as well.
applied patch to HEAD, please verify Curtis
Verified.
*** Bug 252090 has been marked as a duplicate of this bug. ***
