HNHacker News
TopNewBestAskShowJobs

danielshaya

20 karma · joined January 18, 2015

submissionscomments
danielshaya··on How low can you go? Ultra low latency Java in the real world [video]
Completely agree with that 90% of the code I usually work with is not of the 'hot path'.
danielshaya··on Java8 performance – No such thing as a free lunch
Please see my update to this post: http://www.rationaljava.com/2015/01/java8-lambdas-sorting-pe...
danielshaya··on Java8 performance – No such thing as a free lunch
FYI I will be publishing an update to this post (hopefully this week) going through in detail the causes of this performance issues.
danielshaya··on What's Stopping Me Using Java8 Lambdas – Try Debugging Them
I'm the author of the article and very interested reading all the discussion.

Let me explain exactly what the issue is as there seems to have been a bit of confusion about my intentions.

I understand that by stepping into the lambda we are effectively stepping into a new frame analogous to 'stepping into a method' - therefore variables outside the frame will not be visible inside that frame.

But - if we are stepping into a for loop of sorts (or perhaps the lines() method of Files) - you do want to see the other variables in the enclosing method. And the point is that using the old constructs this is exactly what you were able to do.

Java is not functional enough (or at least the way I code isn't) that all the variables I need will be enclosed in the lambda.

In fact when you step into a lambda you retain the scope of the enclosing class (unlike an inner class), so for example when you call toString() you will be printing the toString() of the enclosing object. For this reason it makes sense that in the debugger you should not be considered to have stepped into a new frame when you drop into a lambda.

Ultimately this is all about usability and in real life I have found it extremely frustrating that I can't easily observe the values outside the lambda.