JEP 302: Lambda Leftovers

Martijn Verburg martijnverburg at
Wed Dec 7 20:30:23 UTC 2016

Hi Brian,

On 7 December 2016 at 19:42, Brian Goetz <brian.goetz at> wrote:

> TLDR: I've seen direct evidence of not being able to shadow lambda
>> parameters actually being beneficial for readability.
> I believe you.  Both ways have pros and cons; there are times when it
> forces you to be clearer, and there are times when it just forces you to
> crap up your code.  The debate over this in the original JSR-335 EG
> reflected this.  Ultimately the decision didn't end up getting made on the
> basis of one being demonstrably better than the other -- because no one
> could offer a strong enough argument for either; instead, we hid behind
> that last refuge of scoundrels, "consistency".  Specifically, the scoping
> rules seemed more consistent the way they were originally written, but no
> one was really all that comfortable with the decision.

Apologies for having missed referencing that original discussion, I really
need to be more disciplined about searching the archives first!

> The readability issue is really cropping up a lot with the lambdas code I'm
>> seeing. Many developers are already following a short hand idiom for
>> lambda
>> variables e.g. using 'k' instead of 'key', along with some other idioms
>> that do lessen the readability of lambdas based code in general.
> Yes, this is very tempting.  And for simple lambdas (x -> x + 1), its just
> fine.  But as lambdas get more complicated, developers don't always adjust
> their habits, as you've observed.

> The main place where the current scoping rules bite is when the argument
> of the nested lambda _refers to the same thing_ as the same-named argument
> in the outer lambda.  Such as:
>     Function<K, V> mapGetter k -> map.computeIfAbsent(k, k -> new
> PlaceHolder());

Ouch, yeah seeing code like that makes me as 'Joe/Jane Java' throw my hands
up and hope someone smarter than me understands what's going on.  It's why
I'm particularly happy with these 3 JEPs overall, it's going to reduce
source code confusion.

Here, both k's are the same thing, so calling the second 'kk' seems
> gratuitously specific.  But this is just one use case; there are others
> where multiple names would make the code more readable.


More information about the platform-jep-discuss mailing list