Bugzilla – Full Text Bug Listing
| Summary: | call hierarchy does not finds calls via method references on interface implementations | ||
|---|---|---|---|
| Product: | [Eclipse Project] JDT | Reporter: | Samrat Dhillon <samrat.dhillon> |
| Component: | Core | Assignee: | Manoj N Palat <manoj.palat> |
| Status: | VERIFIED FIXED | QA Contact: | |
| Severity: | major | ||
| Priority: | P3 | CC: | jarthana, knut.wannheden, samrat.dhillon, T3rm1 |
| Version: | 4.6 | ||
| Target Milestone: | 4.6 M7 | ||
| Hardware: | All | ||
| OS: | All | ||
| See Also: |
https://git.eclipse.org/r/70746 https://git.eclipse.org/c/jdt/eclipse.jdt.core.git/commit/?id=d6cbb5f758ded5eeca102e76e753b701b04256d0 https://bugs.eclipse.org/bugs/show_bug.cgi?id=539602 |
||
| Whiteboard: | |||
Reproduced on master. Manoj, please take a look. Also note that searching for references of Bar#print() produces inconsistent results. At times, the reference expression is not reported if the lambda is present. (In reply to Jay Arthanareeswaran from comment #1) >note that searching for references of > Bar#print() produces inconsistent results. At times, the reference > expression is not reported if the lambda is present. Jay: yes, this searching for references with lamda does not highlight method reference expression - Looks more likely as a ui bug as jdt core finds the method reference and calls the accept method. Have submitted bug 484454 against ui to track this issue Just wanted to know if this bug is on the radar and will be fixed in the upcoming release? New Gerrit change created: https://git.eclipse.org/r/70746 Gerrit change https://git.eclipse.org/r/70746 was merged to [master]. Commit: http://git.eclipse.org/c/jdt/eclipse.jdt.core.git/commit/?id=d6cbb5f758ded5eeca102e76e753b701b04256d0 Verified for Neon M7 using I20160425-1300 build Still doesn't work in Eclipse Oxygen if there is more than one implementation. (In reply to T3rm1 from comment #7) > Still doesn't work in Eclipse Oxygen if there is more than one > implementation. With an additional implementation, I still see the call hierarchy. public class BarImpl2 implements Bar{ @Override public void print() { } } Or with an extended class as well, public class BarImpl2 extends BarImpl{ @Override public void print() { } } the call hierarchy is shown. Can you please give an example? In the following example I would have expected the call hierarchy for the method "bar(Test)" to show me "other()", but instead I get "foo()" which isn't really helpful, as that is only where the method reference is.
Hope this test case helps.
public class Test {
public interface Listener {
void process(Test source);
}
public void addListener(Listener l) {
// ...
}
public void foo() {
addListener(this::bar);
}
private void bar(Test test) {
// ...
}
public void other() {
Listener l = null;
l.process(this);
}
}
(In reply to Knut Wannheden from comment #9) > In the following example I would have expected the call hierarchy for the > method "bar(Test)" to show me "other()", but instead I get "foo()" which > isn't really helpful, as that is only where the method reference is. This will be tracked via bug 539602. |
Here is an example to reproduce the problem interface Bar { public void print(); } @FunctionalInterface public interface Foo { void process(Bar bar); } public class BarImpl implements Bar{ @Override //call hierarchy on print does not finds invocation in the below TestMethod class public void print() { } } public class TestMethod { public void test(){ //Foo foo = (bar)->bar.print(); Foo foo = Bar::print; } } Invocation of call hierarchy fails on BarImpl#print however it works on Bar#print. If the method reference expression is replaced with the lambda expression, then it works. Marked this as major as I use this functionality everyday on interface implementations and it is very annoying that such a basic thing does not works.