JEP proposed to target JDK 11: 323: Local-Variable Syntax for Lambda Parameters
Remi Forax
forax at univ-mlv.fr
Sun Jan 28 23:47:06 UTC 2018
Hi Andrew,
----- Mail original -----
> De: "Andrew Haley" <aph at redhat.com>
> À: "Zheka Kozlov" <orionllmain at gmail.com>, "Martijn Verburg" <martijnverburg at gmail.com>
> Cc: "jdk-dev" <jdk-dev at openjdk.java.net>
> Envoyé: Vendredi 26 Janvier 2018 16:09:34
> Objet: Re: JEP proposed to target JDK 11: 323: Local-Variable Syntax for Lambda Parameters
> On 26/01/18 09:59, Zheka Kozlov wrote:
>> The motivation is to allow `final` and annotations on lambda parameters:
>>
>> (final var x) → x + 1;
>> (@Nonnull var x) → x + 1;
>
> I'm trying to understand how it makes sense to have something
> that's both variable and final.
yes, 'final var' is an odd combination, 'var' means more this is a local variable and less this is something which is variable.
In Java, you can declare a parameter of a method final which means it's a local variable that can be only assigned once, given that parameters are assigned with the calling arguments, it means that this parameter can not be re-assigned. This is just a compile time 'annotation', because marking a parameter or a local variable final is not something which is stored in the classfile (apart if you compile with the -parameters, but most people don't).
Some coding conventions, mostly the one from Google mandates that all method parameters are declared final, so since Java 8, some developers have asked to be able to declare lambda parameters final.
In a perfect World, Google should update its coding convention because mandating to declare local variables final has the nasty side effect of blurring the distinction between final for a field which as you know has effects defined by the memory model and final on local variable which has no effect. So mandating to declare local variables final is harmful.
>
> --
> Andrew Haley
> Java Platform Lead Engineer
> Red Hat UK Ltd. <https://www.redhat.com>
> EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671
cheers,
Rémi
More information about the jdk-dev
mailing list