Community
Participate
Working Groups
Sometimes, when I debug, I want to stop execution as soon as it reaches a certain class context to execute certain methods on the class manually. This is useful, for example, when doing GUI development; after I make certain changes to my GUI components I redisplay them by calling an initialization method on the class. Right now, what I have to do is to set a breakpoint on a particular method of the class, and then somehow make my application call that method, which leads to the breakpoint being hit and me being able to manually call my initialization method. Instead of setting a breakpoint on a particular method, I want the breakpoint to be hit on any class method, since that gives me the class context I need to call my initialization method. I don't want to be required to set a breakpoint on a specific method, when all I need is the class context. JBuilder has this feature from what I've seen.
I'm not clear on the request: * Do you want a class load breakpoint (i.e. suspend when the VM loads the class)? * Or, do you want a "stop in any method on this class" breakpoint?
A "stop in any method on this class" breakpoint.
This can be done, but the implementation may have performance problems. This is implemented with "method entry requests" into a specific class. If the target VM implements this inefficiently, then the target program may run/debug slowly.
Breakpoints that stopped in any method of a class should perform better than our existing method breakpoints.
Not true - a method entry breakpoint is currently implemented with a line breakpoint on the method (which is faster than a method entry breakpoint request). Using a method entry request for a type (usually) turns on method tracing in the target VM, which (usually) slows down the target program.
Deferred
Closing, not planning to implement.
As of now 'LATER' and 'REMIND' resolutions are no longer supported. Please reopen this bug if it is still valid for you.
This is a useful feature.. I don't think the sited performance concerns are reason to drop it. If a user were to manually troll thru a class and set a breakpoint at the start of each method, the feature would be, in effect, implemented. You cannot prevent a user from doing that and so the performance issue already exists and has not been reported as an issue (i hope :>). I've done it and hated it with up to 32 methods. Works fine. (matters-not why I can't figure out the entry point by other means). There may be valid performance issue with the manner you envisioned to implement about which I cannot say... but at least look at it from the above perspective. Make it a UI trick, if you must, but please reopen.
Re-opening as per request. Currently no plans to implement.
> If a user were to manually troll thru a class and set a > breakpoint at the start of each method, the feature would be, in effect, > implemented. You can already do that by selecting the methods in the Outline view and then using Toggle Method Breakpoint (from the context menu or the Run menu).
(In reply to comment #11) > You can already do that by selecting the methods in the Outline view and then > using Toggle Method Breakpoint (from the context menu or the Run menu). If the selection contains an abstract method the context menu does not have the 'Toggle Method Breakpoint' option :) , the Run menu has the option though which just skips the abstract method. But the original bug is about *any method* in a class, including inherited methods.
