Bug 560545

Comment 1 Simeon Andreev 2020-02-26 06:54:47 EST

Created attachment 281934 [details]
Screenshot showing only 1 hit for the interface, while more exist.

Comment 2 Simeon Andreev 2020-02-26 07:01:42 EST

Note that I'm not 100% sure whether the Type Hierarchy view is really at fault here, when I examine DebugCommandAction in more detail.

In particular DebugCommandAction does not implement IEnabledTarget, it implements org.eclipse.jface.action.Action.setEnabled(boolean) due to extending Action. Isn't this a violation of type safety, that went past the compiler?

Comment 3 Simeon Andreev 2020-02-26 07:12:33 EST

Getting the implementers of "org.eclipse.debug.internal.ui.commands.actions.IEnabledTarget.setEnabled(boolean)" with ctrl+click -> "Open Implementation" also yields exactly 1 implementer.

Comment 4 Sarika Sinha 2020-02-26 07:14:15 EST

(In reply to Simeon Andreev from comment #0)

> 
> private IEnabledTarget fEnabledTarget = DebugCommandAction.this::setEnabled;

Changing this to 
	private IEnabledTarget fEnabledTarget = enabled -> setEnabled(enabled);

Shows 2 hits for F4.

Comment 5 Simeon Andreev 2020-02-26 07:20:45 EST

Looking at https://docs.oracle.com/javase/tutorial/java/javaOO/methodreferences.html, I think its expected that the code in DebugCommandAction.fEnabledTarget works as it is now. The given example is basically the same as the code in DebugCommandAction. So this bug should be something missing in the type hierarchy computation.

I'm looking at this:

"
Reference to an Instance Method of a Particular Object

The following is an example of a reference to an instance method of a particular object:

class ComparisonProvider {
    public int compareByName(Person a, Person b) {
        return a.getName().compareTo(b.getName());
    }
        
    public int compareByAge(Person a, Person b) {
        return a.getBirthday().compareTo(b.getBirthday());
    }
}
ComparisonProvider myComparisonProvider = new ComparisonProvider();
Arrays.sort(rosterAsArray, myComparisonProvider::compareByName);

The method reference myComparisonProvider::compareByName invokes the method compareByName that is part of the object myComparisonProvider. The JRE infers the method type arguments, which in this case are (Person, Person).
"

Comment 6 Andrey Loskutov 2020-02-26 07:22:37 EST

(In reply to Simeon Andreev from comment #2)
> Note that I'm not 100% sure whether the Type Hierarchy view is really at
> fault here, when I examine DebugCommandAction in more detail.
> 
> In particular DebugCommandAction does not implement IEnabledTarget, it
> implements org.eclipse.jface.action.Action.setEnabled(boolean) due to
> extending Action. Isn't this a violation of type safety, that went past the
> compiler?

In Bytecode Outline view you can see that a method reference object is created by the compiler, that calls at runtime exact the one setEnabled() method defined by the IEnabledTarget so it is qualified here as a field value. As this thing is synthetically inlined by the compiler *inside* the constructor call, this seem to be invisible for the JDT model. The difference to enabled -> setEnabled(enabled) is that for later, an extra synthetic method is created, which is what probably found by the JDT search. I guess if JDT search would inspect INVOKEDYNAMIC instructions, we might see better matches, but I assume JDT search doesn't work on instruction level.

Comment 7 Eclipse Genie 2022-02-16 11:49:00 EST

This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet.

If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant.

--
The automated Eclipse Genie.

Comment 8 Simeon Andreev 2023-03-13 14:51:54 EDT

Opened: https://github.com/eclipse-jdt/eclipse.jdt.core/issues/830