We Keep Coding

Breakpoint filter by subclass?

Is it possible to set breakpoint so that it stop only if the given method is called from subclass?
I.e. both a method defined and breakpoint set are in superclass. Method is not overridden in subclass but is called for it. I need to catch only those cases, when it happen from given subclass.
This is suitable to track incorrect usage in highly branched libraries. For example class VeryCoolAncestor is called 1000 times, while only 1 of the calls are of my buggy class B.
I would like to know if it is possible in Eclipse. If it is not possible in Eclipse, then I would like to know any other debuggers where it is possible.
I need automation, so I don't need to know workarounds like inserting test calls in the code or test overriding methods.

You can use conditional breakpoints in Eclipse.
Right click on the breakpoint, then select "Breakpoint Properties", then enable the "Conditional" checkbox and add an instanceof statement that satisfies your requirements:
Or, you can write a block just for debugging purposes, having one statement:
if(someCondition) {
System.out.println("Breakpoint here");
}

How to generate interface's methods into all implementation classes?

I am looking for some kind of refactoring feature in Eclipse to generate methods in implementation classes from an interface class. Let's say I have JavaClassImpl1 and JavaClassImpl2, which implement JavaClassInterface. What I'd like to do is when I add a method to JavaClassInterface, the refactoring option is to generate empty methods in all implementation classes, in this case, in JavaClassImpl1 and JavaClassImpl2.

If you haven't implemented all of the required methods in eclipse, it will show a bunch of compile-time errors in your class (the class will have a red underline).
If you hover over the class name, a pop-up will appear with available quick fixes, one of which will be Add unimplemented methods. If you select that eclipse will generate a stub for each unimplemented method.
Another way to access the same function is to rightclick in your class and select Source -> Override/Implement Methods... which will pop up a wizard which allows you to select which methods you would like eclipse to stub out for you.
Update
If the change you make to your interface is done via one of the eclipse refactor tools, then eclipse will generally update references to the thing that was changed. For instance, if you do a Refactor -> Introduce Parameter Object... on a method in your interface, then eclipse will automatically update implementing methods.
If you're adding code manually, eclipse doesn't even know about the change until the next time you compile, and you'll have to explicitly ask eclipse to refactor the code.

Eclipse: When displaying a list of methods (ctrl-space), is there a way to have methods in that class - bold?

Eclipse:
When displaying a list of methods (ctrl-space), is there a way to have methods found in that class have names in bold? Netbeans has or at least had a feature that would bold the names of methods found within that class while inherited methods remained normal text.
This made it very easy to know what methods are from within the class you are editing.
Is there a way to do this in the latest version of Eclipse?
Thanks.

It seems eclipse does not support it.
What I do in such cases (workaround):
Open the affected class (Navigate -> Open Type...)
Press CTRL-O, this will show the methods implemented in this class.
Press CTRL-O again, this will also show the inherited methods.

How to display java classes in eclipse calling a method from other class

I was wondering if there is a quick way of identifying or displaying which classes are trying to call a method.
Its easy to do this if there are only few classes present. But what if there are hundreds of classes trying to call a method in other classes. It would be extremly tedious if I do this manually. Is there a plugin or some built-in functions that would do this in eclipse?
The reason am asking is I wanted to map out different classes that are calling methods from other classes for easy debugging.

Right click your function, select references, and then choose what you want (generally project). That will show all the references to this function in the project. This also works for classes, variables, and probably other stuff too.

You can try an eclipse's Call Hierarchy feature. It shows you all the methods which directly call the method you are interested in. You can expand each caller and see what methods call it and so on.
You can do it buy right clicking on the method and selecting an "Open Call Hierarchy" menu item or pressing Ctrl+Alt+H Hotkey.

How to see from where a public method is called in Eclipse using Java?

I am working on a Java project in Eclipse. Sometimes when I do refactoring I would like to see from what other classes a public method is called.
There is a primitive way to do this, that I am using now. I can comment out the method and see in what classes there is an error in Eclipse. Is there any better way to do this in Eclipse? E.g. by selecting the method signature and run a command by a key-shortcut?

Click on the method name, then press Ctrl+Alt+H to bring up the Call Hierarchy view.

You can also use Ctrl+Shift+G for "Find References in Workspace"

Search > References > Workspace
This will build a tree of results in the search view of every reference to the method. The hotkey is Shift+Ctrl+G

Another thing you could do is make it throw an exception (public void test() throws Exception{}) that way eclipse would put errors at every place that calls the method (as long as its not in a try/catch block or it throws an Exception too), this way will only work if you want to search classes in your project.

Cntrl + Shift + G
This shows where the call is made along with the hierarchy.

Eclipse 4.23 (Feb. 2022, 12 years later) does add to this view with:
Show implementations of callee
The call hierarchy view can now show implementing methods as potential callee methods when viewing callees.
This behavior can be controlled from following preference