add support for lambda breakpoints

[gayanper]

trafficstars

Environment

• Operating System: Any
• JDK version: Java8+
• Visual Studio Code version: 1.66.2
• Java extension version: v1.5.0
• Java Debugger extension version: v0.40.1

Steps To Reproduce

1. Try to place a breakpoint into a lambda expression similar to typescript

Current Result

Cannot place the beak-point.

Expected Result

Should be able to place breakpoints like in typescript code.

Additional Informations

It seems methods entry breakpoints are not supported as well. And both these type of breakpoints are not support with upstream jdt debug project.

[testforstephen]

method entry breakpoints are not supported in VS Code Java Debugger yet.

@gayanper Are you talking about lambda entry breakpoint like this https://bugs.eclipse.org/bugs/show_bug.cgi?id=579100? Right?

[rgrunber]

Is this the regression in https://github.com/eclipse-jdt/eclipse.jdt.debug/issues/33 ? Should be fixed for 4.24 M3.

[gayanper]

I was trying to add a lambda breakpoint like what is available in eclipse 2020-03. But in vscode I couldn’t find a way to add the breakpoint into a specific lambda expression in stream expression for example.

[testforstephen]

I see Eclipse has separate menus to toggle Lambda Entry Breakpoint and Function Breakpoint, we don't have similar capabilities in VS Code yet. Currently only line breakpoints are supported, where you can set a breakpoint inside a lambda body.

Is this the regression in https://github.com/eclipse-jdt/eclipse.jdt.debug/issues/33 ? Should be fixed for 4.24 M3.

Yes, we also find in some cases the line breakpoints inside lambda body are not working. For example, breakpoints under stream().forEach() can be hit, but breakpoints under stream().map() will be skipped.

		List<String> users = Arrays.asList("Lambda");

		users.stream().forEach(u -> {
			System.out.println("user name: " + u); // Breakpoint at this line can be hit
		});

		users.stream().map(u -> {
			return u;  // breakpoint at this line will be skipped.
		});

[gayanper]

@testforstephen I cannot remember top of my head we added the lambda breakpoint toggle as a public API or not. But if we do in jdt debug, could we make use of vscode support for adding breakpoints in lambda starting point. I see that it is available for javascript and typescript at least.

[gayanper]

The correct vscode term is the inline breakpoints, which can be added today even thought they are treated as normal line breakpoints. I will check more and see if we can provide some support in jdt debug for this. The reason i'm more focused on this feature is that to add support for java on cloud ready IDEs such as eclipse che for example.

[gayanper]

Further looking at i found the vscode send us the column number we added the inline breakpoint. But since our java types doesn't have that we don't receive at SetBreakpointRequest handler. What remaining is that we should be able to look at the AST from jdtls at that location and see if we have a lambda expression (not a lambda block). From that we should be able to resolve the lambda method name by doing a org.eclipse.jdt.core.ICodeAssist.codeSelect(int, int) and create an entry breakpoint.

[snjeza]

The correct vscode term is the inline breakpoints, which can be added today even thought they are treated as normal line breakpoints.

It works in VS Code Java.

I have used: VS Code 1.67 VS Code Java: 1.6.0 Java: embedded (17.0.2) Fedora 35 Xorg

[snjeza]

Yes, we also find in some cases the line breakpoints inside lambda body are not working. For example, breakpoints under stream().forEach() can be hit, but breakpoints under stream().map() will be skipped.

This is an Eclipse upstream issue. I can reproduce it in Eclipse I20220507-1800 and master.

[testforstephen]

The correct vscode term is the inline breakpoints, which can be added today even thought they are treated as normal line breakpoints.

It works in VS Code Java.

I have used: VS Code 1.67 VS Code Java: 1.6.0 Java: embedded (17.0.2) Fedora 35 Xorg

Interesting. When setting inline breakpoints in VS Code, Java Debugger only respects line numbers but ignores the column numbers, they will actually be taken as line breakpoints. It seems registering line breakpoints on the same line twice can handle the case of having inline lambda body in one line well.

But the approach @gayanper mentioned above should be a better approach to handle inline breakpoints systematically.

[gayanper]

@testforstephen i think setting a line breakpoint in java debugger stops on all locations in that line. When you have in-line lambda, the location includes the entry point of that lambda method as well. It works in other Eclipse the same way without any special treatment.

[testforstephen]

@testforstephen i think setting a line breakpoint in java debugger stops on all locations in that line.

Have a look again, VS Code Java Debugger provides the same behavior. When setting a breakpoint in a line, VS Code Java Debugger actually will register BreakpointRequests at all valid locations in that line. The valid locations are fetched from the JDI API ReferenceType#locationsOfLine(int lineNumber), which returns all statement locations in that line, but not the entry point of a lambda expression.

[testforstephen]

Closing it since this has been supported in latest debugger version.