Comment 1 Markus Keller 2012-01-23 09:48:38 EST

> 2. Open the Call Hierarchy on Sub.called()
> ==> it lists Super.callIt() but that's wrong since Sub.callIt() does not call
> super.callIt().

Sub.callIt() indeed doesn't call Sub.called(), but Super.callIt() still does. To know that this call path is never executed in practice, we would need a full system analysis.

The result is OK in general, see example below where this call actually happens in practice via Sub.callItDetour().

The best we can do is to offer a filter for calls to overridden methods, like bug 73401 did for reference search.


package p;
public class Super {
    void callIt() {
        called();
    }
    void called() {
        System.out.println("called Super");
    }

    public static void main(String[] args) {
        new Sub().callIt();
        new Sub().callItDetour();
    }
}

class Sub extends Super {
    void callItDetour() {
        super.callIt();
    }
    
    void callIt() {
        System.out.println("BUG");    
    }

    void called() {
        System.out.println("called Sub");    
    }
}

Comment 2 Stephan Herrmann 2016-12-12 12:27:05 EST

(In reply to Markus Keller from comment #1)
> The best we can do is to offer a filter for calls to overridden methods,
> like bug 73401 did for reference search.

In case of a single search, a user has good chances to "just know" that receivers will have a particular type and not another. In the Call Hierarchy this is more problematic because each call in a chain can be polymorphic and it's unlikely that a user has precise type information for all these calls.

Ideally, I would imagine a context menu action "Restrict callee type" or "Filter polymorhpic calls", which could be invoked on each node in the hierarchy to filter just the incoming edges to this particular node. Not sure, though, if this is overkill. But disabling polymorphic search for the entire Call Hierarchy feels wrong to me.