Community
Participate
Working Groups
Currently you can set method entry breakpoints on abstract methods (in interfaces or otherwise). The breakpoints are installed but never appear to be hit in the manner I would expect: the concrete implementation is entered, the breakpoint is hit. What is the intended behavior here?
There was no intended behavior - the action can either be disabled for interfaces, or we have to spec/implement the behavior. For now, disabling the action is easiest (I think), and then defer the feature request for later.
Disable the method breakpoint action for interfaces. The behavior is currently unspecified. We would need to track type hierarchies as they change, and keep a 1:N mapping of underlying breakpoints in concrete types.
The action is no longer visible for abstract methods. Changes to MethodActionFilter.
Please verify Darin.
The action is still enabled for in the "Run" menu.
I have improved this but the action will sometimes be enabled but will beep when attempted. If the current selection is from the outliner, the Run menu action will be disabled. If the current selection is from the editor, the Run menu action will be enabled but will beep and not create a breakpoint. The reason for the differences: from the outliner we have the method to deal with. From the editor we may need to do a reconcile to correctly resolve the java element (not yet in this case but soon see bug 1552). The reconcile is expensive and is only performed when the user has explicitly asked to run the action. Should I create an error dialog for the failure case?
Note that this is not a regression...the same behavior has existed for the Add Watchpoint action for some time.
An error dialog woulld be good - i.e. explaining that a method breakpoint cannot be placed on an abstract method.
Error dialogs have been added for both watchpoints and method entry breakpoints.
Please verify.
Verified.
