JEP proposed to target JDK 11: 323: Local-Variable Syntax for Lambda Parameters

Martijn Verburg martijnverburg at gmail.com
Fri Jan 26 09:18:52 UTC 2018


Continuing train of thought (sorry it's late here in NZ, so I'm not being
as coherent as I should be).  I guess (var x, var y) vs (x, y) adds another
possible use case where you'll see two idiomatic styles of Java being
written in the wild. This is something which Java usually tries to avoid?
Although there are of course very good use cases where breaking from an old
idiom is very desirable.

Cheers,
Martijn

On 26 January 2018 at 22:14, Martijn Verburg <martijnverburg at gmail.com>
wrote:

> I'd be interested in some empirical numbers around the usage in Groovy of
> the two styles of declaration!
>
> I'm also trying hard not to get caught up only thinking about syntax here.
> I know that I'm someone who's not a qualified language or VM expert and
> that I've more than likely got caught up thinking about the wrong problem
> (syntax vs semantics).
>
>
>
>
>
> Cheers,
> Martijn
>
> On 26 January 2018 at 21:38, Cédric Champeau <cedric.champeau at gmail.com>
> wrote:
>
>> Hi Martijn,
>>
>> I share your thoughts. I understand the will to streamline the use of
>> "var". However, since
>>
>> (var x, var y) -> x+y
>>
>> is strictly equivalent to:
>>
>> (x,y) -> x+y
>>
>> I'm not sure I see the advantage of this. From my experience with Groovy,
>> where both are supported ( { def x, def y -> ) and ( { x,y ->), I think
>> most people stick with the short syntax, the longer one seems to imply
>> different semantics (why use a different syntax if its the same ?), where
>> there are not.
>>
>> 2018-01-26 9:30 GMT+01:00 Martijn Verburg <martijnverburg at gmail.com>:
>>
>> > Hi all,
>> >
>> > I'm struggling to understand the motivation for this JEP in terms of it
>> > adding improved understanding or readability of source code (as the
>> > implicit case is already covered today).
>> >
>> > I also suspect the illegal use uses (extract below) will likely confuse
>> and
>> > frustrate day to day developer's who don't understand the underlying
>> type
>> > inference system and lead to
>> > some heavily upvoted SO Q's.  I liken this type of frustration seen in
>> > developers not understanding generics in full and coming undone in
>> corner
>> > cases where they expect the element of
>> > 'least surprise'.
>> >
>> > ------
>> >
>> > The following examples are illegal:
>> >
>> > (var x, y) -> x + y        // Cannot mix var and "no var" in
>> > implicitly typed lambda expression
>> > (var x, int y) -> x + y    // Cannot mix var and manifest types in
>> > explicitly typed lambda expression
>> >
>> >
>> > -------
>> >
>> > I'm not sure I've explained myself very eloquently here, hope this has
>> made
>> > some sense.
>> >
>> > Cheers,
>> > Martijn
>> >
>> > On 26 January 2018 at 08:40, <mark.reinhold at oracle.com> wrote:
>> >
>> > > The following JEP is proposed to target JDK 11:
>> > >
>> > >   323: Local-Variable Syntax for Lambda Parameters
>> > >        http://openjdk.java.net/jeps/323
>> > >
>> > > Feedback on this proposal is more than welcome, as are reasoned
>> > > objections.  If no such objections are raised by 23:00 UTC on
>> Thursday,
>> > > 1 February, or if they're raised and then satisfactorily answered,
>> then
>> > > per the JEP 2.0 process proposal [1] I'll target this JEP to JDK 11.
>> > >
>> > > - Mark
>> > >
>> > >
>> > > [1] http://cr.openjdk.java.net/~mr/jep/jep-2.0-02.html
>> > >
>> >
>>
>
>


More information about the jdk-dev mailing list