Community
Participate
Working Groups
For debugging OO code, it would be useful if I could set a method breakpoint on an abstract method (class or interface). That breakpoint would hit whenever one of the method's implementors is called. To achieve this effect, I currently have to either set a breakpoint at every call site of the method, or manually set a method breakpoint on every implementing method.
I thought we already had a deferred feature request for this, but I can't find it now. Marking as later.
*** Bug 196494 has been marked as a duplicate of this bug. ***
Also adding note that users would like to be able to add breakpoints on interface methods to stop in all concrete implementations.
Any chance of getting the status/resolution updated? This would be a very nice feature to have.
*** Bug 213016 has been marked as a duplicate of this bug. ***
Re-open for bugday.
Sorry, no resources to allocate to this enhancement currently.
Created attachment 124458 [details] proposed patch I had some resources and created a patch which adds this feature :) They idea is simple: when user toggles breakpoint on an abstract method then it gets declaring type of that method, creates its type hierarchy, finds its subtypes and their implementations of that abstract method and sets/removes method breakpoints on them. The only problem is that it has some overhead (I think this is because of creating type hierarchy but I'm not sure if it can be avoided in any way). I look forward to your feedback.
I have not looked at the patch, but here are some issues to think about: * If mulitple breakpoing markers are created from the original interface breakpoint, can they be deleted as a group? (does the user have to delete them all?) * If new classes are added do new breakpoints get added? To avoid these problems we could insert the breakpoint at class load time instead. However, that requires listening to all class loads, which can be a performance problem.
1. Multiple breakpoints are deleted as a group when you delete a breakpoint on an abstract/interface method. This has a side effect that when you put a breakpoint on a method which is implementation of an abstract method, then put a breakpoint on that abstract method and remove breakpoint on abstract method then the original breakpoint is removed as well. 2. When you add a new class new breakpoints are not added so you have to remove breakpoint at abstract method and create it again. So I see that there are 2 solutions: - putting a breakpoint on abstract method immediately puts breakpoint on all of its implementations - dynamically adding breakpoints at debug time The second solution solves problem 2 but seems (to me) to be more difficult to implemented. Also with first solution the breakpoints on every method are always visible. This may be more intuitive for users.
I would prefer an approach where I only have to deal with one breakpoint on the abstract method.
I'd also prefer a single breakpoint and having the debugger deal with behind the scenes.
I recall a long time ago we had to reduce our JDI traffic listening for all class load/prepare events (but cannot find the bug right now). It was causing startup time for debugging to be too slow. So, having things happen just on the VM side may not be a possible solution (i.e. better to know all breakpoint locations in advance of debugging). I could imagine a solution where one breakpoint is created by the user, which creates "secondary" breakpoints in the workspace. Ideally, these would not have to be user managed - but would be visible with a special icon so the user knows the breakpoints are present (and why). The icon could have an "interface" or "abstract" overlay. It would be nice to group these icons in the breakpoints view - showing the secondary breakpoints as children of the primary breakpoint. Deleting a secondary breakpoint could prompt the user to delete all in the group, or allow select secondary breakpoints to be disabled. This solution would also have to respond to workspace changes - as new types are added/created, the breakpoint would have to assess whether to add additional breakpoints. Although the platform supports breakpoint groups, the grouping in the breakpoints view is currently controlled by the user. This would be another reason to support "flexible hierarchy" in the breakpoints view, similar to other debug views. I'm not sure we have all the infrastructure in place to properly support this.
The debug team is willing to review contributions but does not have resources to implement this feature currently. Removing target milestone pending contributions.
*** Bug 344812 has been marked as a duplicate of this bug. ***
Will like to analyze it for 4.6 M4
Have started analyzing, but need some more time.
Proposal to solve this problem: 1. Add a new AbstractMethodBreakpoint type to differentiate between Manual and system added breakpoints. This will help user in identifying the breakpoints and will help the system to manage them in case of removal. 2. To provide an action(manual or automated driven by preference) on workspace/project/file to synchronize the breakpoints. This can handle the addition of new classes in the hierarchy. It can also handle the stale breakpoint problem like Bug 310478, which we have not been able to handle due to possible threading issues and launch time impact.
(In reply to Sarika Sinha from comment #18) Sounds good, and similar to comment 13. But as said there, the problem will be how to implement point 2 efficiently. To manage changing type hierarchies, the most efficient way would probably be ITypeHierarchy#addTypeHierarchyChangedListener(..). But that would not help with bug 310478. Another problem will be that the breakpoints on the subtypes will only work for types that are present in the workspace. To fix that, the implementation would have to create type hierarchies in the target VM.
Will wait for the implementation of new Index search in Java core(Bug 481796 ) and it's impact on the performance of hierarchy calculation.
