Hacker News Reader

Comment by the8472 | Hacker News Reader

> therefore variables outside the frame will not be visible inside that frame.

You know that the debugger can traverse the stack and show variables for the outer frames (assuming the lambda is invoked down-stack, as in your example), right? This is just a visualization issue of the debugger you're using and not a problem with lambdas themselves.

Javascript debuggers had to deal with this (the scope chain) for much longer, that's why variable views of JS debuggers show the whole scope chain instead of just the local frame.

View on HN

> This is just a visualization issue of the debugger you're using

No it's not - it's (apparently) a JDK issue. See the discussion in the Jetbrains bug report. BTW if Eclipse can do this, Jetbrains want to know.

Is this[1] not what you want? Modulo a better UI of course.

[1] http://i.imgur.com/bwWvk0I.png

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!

Sure, here you go: http://i.imgur.com/posDGaB.png

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.

Where did "e" get declared at? It just seems to leap magically into existence.

List<T>#forEach takes a Consumer<? super T>

Consumer<U> has a single abstract method

void accept(U u)

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.

Reply on news.ycombinator.com