A method breakpoint allows you to specify a breakpoint by method name instead of by line number. This has the advantage over line breakpoints in that you less frequently need to adjust a method breakpoint after you edit the source file. However, method breakpoints can only pause execution at the beginning of a method. If you need to pause somewhere within a method you need to use line breakpoints instead.
You may also have problems setting breakpoints on methods whose names are overloaded (ie. same method name used multiple times with different parameter types and/or different number of parameters). This is because BugSeeker currently is only able set method breakpoints by method name only and because you are not able to further specify which method to use when the name is overloaded it is hard to predict which method the method breakpoint will be set. The workaround is to revert back to using line breakpoints.
Method breakpoints are encountered whenever the method it is set for is invoked for the class specified with the method breakpoint. The method does not have to be actually defined in the specified class nor does it need to be inherited (may be private in an ancestor class); the breakpoint will also pause the session if a similarly named method is invoked in the specified class's superclass. The actual way in which method breakpoints are set is that BugSeeker will take the specified class in which the method breakpoint is to be set for and searches for the first method with the specified name in the class's hierarchy starting with the class itself. If there is such a method, a method breakpoint will be set for that method. All Java visibility rules are ignored when this search is performed.
For example, if you have a class name Foo which does not have any methods and you set a method breakpoint for the inherited method named toString for class Foo, whenever toString() is called on an instance of Foo or a subclass of Foo, execution will be pause at the start of Object.toString()'s method.