Bug 533524

Summary: [call hierarchy] call hierarchy should show lambdas
Product: [Eclipse Project] JDT Reporter: Sam Davis <sam.davis>
Component: UIAssignee: Zsombor G <gzsombor>
Status: RESOLVED FIXED QA Contact:
Severity: enhancement    
Priority: P3 CC: arend, daniel_megert, gzsombor, javaeecoding, jfrantzius, loskutov, max.bureck, noopur_gupta, stephan.herrmann, steve
Version: 4.8Keywords: noteworthy
Target Milestone: 4.22 M2   
Hardware: All   
OS: All   
See Also: https://bugs.eclipse.org/bugs/show_bug.cgi?id=498498
https://git.eclipse.org/r/c/jdt/eclipse.jdt.ui/+/185428
https://bugs.eclipse.org/bugs/show_bug.cgi?id=576619
https://git.eclipse.org/c/jdt/eclipse.jdt.ui.git/commit/?id=9063fc899516a5f3d27eb495c9b19b03ac20e325
https://git.eclipse.org/r/c/www.eclipse.org/eclipse/news/+/186625
https://git.eclipse.org/c/www.eclipse.org/eclipse/news.git/commit/?id=4b8a232a8db07c57b4b5196dbacd68cfeb629444
Whiteboard:
Attachments:
Description Flags
Slightly modified patch shows [declaration] matches for lambdas none

Description Sam Davis CLA 2018-04-12 16:25:56 EDT
Similar to how the call hierarchy shows a constructor invocations node for anonymous classes, it should show the callers of the method in which a lambda appears. Since lambdas are basically just syntactic sugar for anonymous classes I expected this would work. Not having this makes the call hierarchy much less useful for Java 8 code.
Comment 1 Stephan Herrmann CLA 2018-04-12 17:03:56 EDT
One issue is: how do we name that node? In the other bug I mentioned constructor invocations (for anonymous) as an analogy, but obviously, a lambda has no constructor.

If a lambda is defined within a method, then s.t. like "declaring method" could perhaps be used. Lambdas in (field,instance,static) initializers have no interesting incoming flow in this regard, do they?

As a downside, all lambda expressions would have two intermediate nodes with little information added:
  () -> {}
    + [declaring method] foo()
    + [callers]

Just saying.
Comment 2 Sam Davis CLA 2018-04-12 20:28:01 EDT
I contend that in at least 90% of cases the user is only interested in the [declaring method] node and not the callers of the lambda. Lambda's are normally used for interfaces like Function which have thousands of implementations and are used all over the place, so seeing the list of all callers is not useful at all.

> If a lambda is defined within a method, then s.t. like "declaring method" could
> perhaps be used. Lambdas in (field,instance,static) initializers have no
> interesting incoming flow in this regard, do they?

That's right. It would very useful if the call hierarchy could show relationships other than just method calls, e.g. if a lambda (or just a method call) is used in an instance or field initializer, it could show calls to the declaring class's constructor, but that is out of scope of this bug.
Comment 3 Andrey Loskutov CLA 2021-09-20 08:45:02 EDT
*** Bug 575985 has been marked as a duplicate of this bug. ***
Comment 4 Andrey Loskutov CLA 2021-10-11 06:03:37 EDT
Created attachment 287293 [details]
Slightly modified patch shows [declaration] matches for lambdas

Screenshot for slightly changed patch: https://git.eclipse.org/r/c/jdt/eclipse.jdt.ui/+/185428

Instead of "[declaring method]" use [declaration], to avoid confusion on fields etc? WDYT?

Beside this, I found this patch very useful, I would like to merge that ASAP :-).
Comment 5 Andrey Loskutov CLA 2021-10-11 06:04:29 EDT
(In reply to Andrey Loskutov from comment #4)
> Created attachment 287293 [details]

Here is the corresponding snippet to try:

import java.util.List;
import java.util.function.Function;

public class Snippet {
	static Function<? super String, ? extends String> mapper1 = y -> transform(y);
	Function<? super String, ? extends String> mapper2 = y -> transform(y);

	static {
		 mapper1 = y -> transform(y);
	}

	public Snippet() {
		mapper2 = y -> transform(y);
	}

	public static void main(String[] args) {
		mapper1 = y -> transform(y);
	}

	Object[] funcCall() {
		return List.of("aaa").stream().map(y -> transform(y)).toArray();
	}

	static String transform(String s) {
		return s.toUpperCase();
	}
}
Comment 6 Andrey Loskutov CLA 2021-10-14 03:07:50 EDT
Anyone has any objections for merge? With no feedback here or on the patch I plan to merge proposed patch today evening CET.
Comment 7 Noopur Gupta CLA 2021-10-14 06:48:56 EDT
Thanks, Zsombor and Andrey for the patch. Looks good and can be merged for further feedback.
Comment 9 Andrey Loskutov CLA 2021-10-15 02:12:52 EDT
Build I20211014-1800 contains the patch, I've verified it works as proposed.
Please test & provide feedback, ideally before next week M2.

See https://download.eclipse.org/eclipse/downloads/drops4/I20211014-1800/

@Zsombor: would you please prepare N&N entry?

Repo is https://git.eclipse.org/r/www.eclipse.org/eclipse/news.git
Comment 10 Andrey Loskutov CLA 2021-10-18 12:19:27 EDT
(In reply to Andrey Loskutov from comment #9)
> @Zsombor: would you please prepare N&N entry?

ping.
Comment 11 Zsombor G CLA 2021-10-18 16:53:55 EDT
I hope, this makes sense: https://git.eclipse.org/r/c/www.eclipse.org/eclipse/news/+/186625/1
Comment 13 Andrey Loskutov CLA 2021-10-20 10:18:41 EDT
(In reply to Zsombor from comment #11)
> I hope, this makes sense:
> https://git.eclipse.org/r/c/www.eclipse.org/eclipse/news/+/186625/1

Yes, it does :-) Many thanks!
Comment 14 Andrey Loskutov CLA 2022-04-13 12:03:37 EDT
*** Bug 468561 has been marked as a duplicate of this bug. ***