The lambda expression composed of two parts, one is an argument and another one is code or expression. These two parts have separated by an arrow operator "->". We can use different IDE's like Netbeans, IntelliJ, and Eclipse to debug the lambda expressions in Java.
The Stream debugger is a hidden gem for working with Java Streams. Check out this tutorial to learn how to debug Java streams with IntelliJ. Streams are very powerful and can capture the gist of your intended functionality in just a few lines.
Run your application with the debugger ⌃D (macOS), or Shift+F9 on Windows and Linux. Again, you can click the run icon over in the gutter on the left on line 21 if you prefer. On the right-hand side of the debug window, click the button called Trace Current Stream Chain.
I usually have no problem debugging lambda expressions while using Eclipse or IntelliJ IDEA. Just set a breakpoint and be sure not to inspect the whole lambda expression (inspect only the lambda body).
Another approach is to use peek
to inspect the elements of the stream:
List<Integer> naturals = Arrays.asList(1,2,3,4,5,6,7,8,9,10,11,12,13);
naturals.stream()
.map(n -> n * 2)
.peek(System.out::println)
.collect(Collectors.toList());
UPDATE:
I think you're getting confused because map
is an intermediate operation
- in other words: it is a lazy operation which will be executed only after a terminal operation
was executed. So when you call stream.map(n -> n * 2)
the lambda body isn't being executed at the moment. You need to set a breakpoint and inspect it after a terminal operation was called (collect
, in this case).
Check Stream Operations for further explanations.
UPDATE 2:
Quoting Holger's comment:
What makes it tricky here is that the call to map and the lambda expression are in one line so a line breakpoint will stop on two completely unrelated actions.
Inserting a line break right after
map(
would allow you to set a break point for the lambda expression only. And it’s not unusual that debuggers don’t show intermediate values of areturn
statement. Changing the lambda ton -> { int result=n * 2; return result; }
would allow you to inspect result. Again, insert line breaks appropriately when stepping line by line…
IntelliJ has such a nice plugin for this case as a Java Stream Debugger plugin. You should check it out: https://plugins.jetbrains.com/plugin/9696-java-stream-debugger?platform=hootsuite
It extends the IDEA Debugger tool window by adding the Trace Current Stream Chain button, which becomes active when debugger stops inside of a chain of Stream API calls.
It has nice interface for working with separate streams operations and gives you opportunity to follow some values that u should debug.
You can launch it manually from the Debug window by clicking here:
Debugging lambdas also works well with NetBeans. I'm using NetBeans 8 and JDK 8u5.
If you set a breakpoint on a line where there's a lambda, you actually will hit once when the pipeline is set up, and then once for each stream element. Using your example, the first time you hit the breakpoint will be the map()
call that's setting up the stream pipeline:
You can see the call stack and the local variables and parameter values for main
as you'd expect. If you continue stepping, the "same" breakpoint is hit again, except this time it's within the call to the lambda:
Note that this time the call stack is deep within the streams machinery, and the local variables are the locals of the lambda itself, not the enclosing main
method. (I've changed the values in the naturals
list to make this clear.)
As Marlon Bernardes pointed out (+1), you can use peek
to inspect values as they go by in the pipeline. Be careful though if you're using this from a parallel stream. The values can be printed in an unpredictable order across different threads. If you're storing values in a debugging data structure from peek
, that data structure will of course have to be thread-safe.
Finally, if you're doing a lot of debugging of lambdas (especially multi-line statement lambdas), it might be preferable to extract the lambda into a named method and then refer to it using a method reference. For example,
static int timesTwo(int n) {
return n * 2;
}
public static void main(String[] args) {
List<Integer> naturals = Arrays.asList(3247,92837,123);
List<Integer> result =
naturals.stream()
.map(DebugLambda::timesTwo)
.collect(toList());
}
This might make it easier to see what's going on while you're debugging. In addition, extracting methods this way makes it easier to unit test. If your lambda is so complicated that you need to be single-stepping through it, you probably want to have a bunch of unit tests for it anyway.
Just to provide more updated details (Oct 2019), IntelliJ has added a pretty nice integration to debug this type of code that is extremely useful.
When we stop at a line that contains a lambda if we press F7 (step into) then IntelliJ will highlight what will be the snippet to debug. We can switch what chunk to debug with Tab and once we decided it then we click F7 again.
Here some screenshots to illustrate:
1- Press F7 (step into) key, will display the highlights (or selection mode)
2- Use Tab multiple times to select the snippet to debug
3- Press F7 (step into) key to step into
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With