Breakpoints for Java lambdas.

[lahodaj]

This is something I was looking at long time ago, but was not very happy about the UI. So I was trying to improve the UI, but I didn't make progress on that, and this got stashed. So, now I decided to try to recover this, even with the not-so-nice UI.

I would consider this patch to be a fairly advanced prototype.

Currently, having code like:

        List.of("a", "b", "c")
            .stream()
            .map(s -> s).filter(s -> !s.isEmpty())
            .forEach(s -> System.err.println(s));
    }

putting a breakpoint at the line with map will mean the debugger will stop at the line when map is called, and then each time any of the lambdas is called. This is rarely what one wants. It would be better to be able to say that I want the debugger to stop at e.g. the first lambda.

This is what this PR is trying to do. There's an ability to specify the breakpoint applies to n-th lambda on the given line. Special values are -1, which means to stop at the line outside of any lambda, and Integer.MIN_VALUE, which means stop each time this line is reached, regardless of any lambdas. This is the way it works on the backend.

Inside the NetBeans UI, it works like this:

• when a line breakpoint is added on a line with lambdas, it is considered to be on the line only, and there's a disable lambda breakpoint added for each lambda automatically. These can then be enabled/disabled independently.
• when the line breakpoint is removed, all the lambda breakpoints are removed as well.

The ability is also used in the DAP Java server, for use in DAP clients (e.g. in VS Code). The UI in VS Code is better, but also has some sharp edges.

Inside NB, it can look like this:

---

^Add meaningful description above

Click to collapse/expand PR instructions

By opening a pull request you confirm that, unless explicitly stated otherwise, the changes -

• are all your own work, and you have the right to contribute them.
• are contributed solely under the terms and conditions of the Apache License 2.0 (see section 5 of the license for more information).

Please make sure (eg. git log) that all commits have a valid name and email address for you in the Author field.

If you're a first time contributor, see the Contributing guidelines for more information.

If you're a committer, please label the PR before pressing "Create pull request" so that the right test jobs can run.

PR approval and merge checklist:

1. Was this PR correctly labeled, did the right tests run? When did they run?
2. Is this PR squashed?
3. Are author name / email address correct? Are co-authors correctly listed? Do the commit messages need updates?
4. Does the PR title and description still fit after the Nth iteration? Is the description sufficient to appear in the release notes?

If this PR targets the delivery branch: don't merge. (full wiki article)

[matthiasblaesing]

• I think the "don't break in lambda by default" is not a good approach. My reasoning: The feature is hard to discover, so without knowledge of this PR I would come to the conclusion "NetBeans can't break in lambdas". Breaking on the line outside the lambda (i.e. before execution of the chain) is IMHO the least interesting breakpoint as the intermediate steps are what I would be interested in.

• The don't break by default setting is also harmful for people using multiple lines to make the lambda readable. Today they can set a break point and it will work as expected. With this the breakpoint you can set without hassle is basicly useless. I mean this formatting:

• The lambda breakpoint enablement is unstable. Consider this starting point (nothing is running right now):

When I invoke "Debug file", the activation of the lamdba breakpoint is lost (see lambda index 2):

What I wonder in summary is: Isn't this "just" another "condition"? The ability to break in lambda is already there, at least I can set a break point for the example in the row with multiple lambdas and get multiple stops, that match what I would expect for the lambda execution. What is missing from that POV is "just" a filter to select the right lambda(s).

The drawback I see is, that the multiple breakpoints would allow more flexibility (independent counts for conditionally enabled breakpoints, conditions, log output).

[lahodaj]

@matthiasblaesing, thanks for trying. I guess what you are saying is that:

• by default, the breakpoints should stop everywhere (i.e. the lambda index should be Integer.MIN_VALUE in the current internal meaning)
• the automatically added lambda breakpoints should be dropped.

That way, anyone could go to the settings and specify the lambda index. (+the UI maybe could be slightly better e.g. a combobox showing "Everywhere"/"Main Line Only"/"Lambda 1"/"Lambda 2"/...). Note the breakpoint properties already allow to set the lambda index in this prototype.

I can't say I disagree with that. The automagically setup breakpoints where a bit preparation for a (much) better UI (similar to what VS Code is doing), but I don't have the UI, and I don't know if I ever will. So maybe this is simply too complex. And it can be resurrected if we have the better UI.

[matthiasblaesing]

Yes you understood my point correctly. I'm not opposed to multiple breakpoints in general, but from a UI/UX perspective I think making the options available in the line break point might be more realistic as the UI impact would be smaller.

I think it would be good if the "lamdba" "condition" would allow to select multiple lambdas, for this example (in reality I expect lambdas with more interesting content in it 😄):

public class Test3 {

    public static void main(String[] args) {
        List.of("a", "b", "c")
                .stream()
                .map(s -> s.trim()).filter(s -> !s.isEmpty()).forEach(s -> System.err.println(s));
    }
}

it might make sense to break on the first and last lamdba. That way you can observe what goes into the stream pipeline and what reaches the end.