I'm not associated with them, but they asked me for an eclipse screenshot if I had one, when I reported this issue to them and suggested that they create a workaround in their UI. (FWIW it's an annoying issue, but not enough for _me_ to stop using lambdas.)
If you have time, could you make the lambda a multi line chunk of code, so that it's clear that the breakpoint is inside the lambda? I'll pass it on to them. Thanks!
Of course this only works for cases where the debugger can tie the lambda used as method argument to another stack frame, i.e. it doesn't help with async invocations. But in async cases one cannot expect the JVM to lug around the whole stack frame from the time it was created, that could lead to memory leaks.
And from what I've gathered the Jetbrains bug may not talking about the same thing as the blog postis discussing. Their case is about a captured variable that gets inlined in some way that makes debugging difficult, OP is about inspecting arbitrary, non-captured variables in the debugger.
The lambda effectively is an anonymous class implementing that interface / that single method. U resolves to ? super String. I.e. it expects a method that takes String or a superclass thereof as its first parameter.
That's what e is. It all gets automatically pieced together at compile time via type inference.
[1] http://i.imgur.com/bwWvk0I.png