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

[forax at univ-mlv.fr]

Ok, cool, my bad on that. 

Rémi 

> De: "Jeremy Manson" <jeremymanson at google.com>
> À: "Jonathan Bluett-Duncan" <jbluettduncan at gmail.com>
> Cc: "Remi Forax" <forax at univ-mlv.fr>, "jdk-dev" <jdk-dev at openjdk.java.net>
> Envoyé: Lundi 29 Janvier 2018 06:43:49
> Objet: Re: JEP proposed to target JDK 11: 323: Local-Variable Syntax for Lambda
> Parameters

> We do not require method parameters to be final. It isn't referenced at all in
> our style guide, but we have very copious internal Java best practices
> documentation; this is a very slightly modified version of the relevant
> passage:
>> On parameters and local variables [ http://go/java-practices/final#params_locals
>> | link ] [
>> https://cs.corp.google.com/#piper///depot/eng/doc/devguide/java/practices/final.md&edit=1&l=76
>> | mode_edit ] [
>> https://engdoc.corp.google.com/eng/doc/devguide/java/practices/final.md?cl=head#
>> | comment ]

>> It would be nice if Java made parameters and local variables final by default.
>> Since the need to allow reassignment is both more rare and more risky, it makes
>> sense to be opt-in. Unfortunately, Java got this backward.

>> Some developers prefer to mark all their parameters and local variables final
>> unless they are reassigned. There are good reasons for this, but it is not
>> clear that the advantages outweigh the costs (lower signal-to-noise, and
>> especially burden of enforcement)—and so this practice is not favored at
>> Google.

>> Remember that the dangers of sloppy reassignment of locals will be limited if
>> you always keep your methods short and focused. And note that as of Java 8 it's
>> no longer necessary to use final on local variables to make them accessible
>> from an inner class.

>> Of course, you can still use final on a local variable when it serves some
>> specific purpose. For example, you might use a [
>> https://en.wikipedia.org/wiki/Final_(Java)#Blank_final | blank final ] to
>> signal that while you do intend to "modify" (set) the value later, you'll do it
>> only once.

>> Available solution: projects can [ http://go/errorprone/bugpatterns#optional |
>> opt in ] to [ http://errorprone.info/bugpattern/Var | @Var Error Prone
>> enforcement ] . This inverts the default: the Error Prone check requires all
>> modified parameters and local variables to be explictly annotated with @Var .
> Jeremy

> On Sun, Jan 28, 2018 at 4:02 PM, Jonathan Bluett-Duncan < [
> mailto:jbluettduncan at gmail.com | jbluettduncan at gmail.com ] > wrote:

>> Hi Rémi,

>> You may find my (short) response inline.

>> On 28 January 2018 at 23:47, Remi Forax < [ mailto:forax at univ-mlv.fr |
>> forax at univ-mlv.fr ] > wrote:

>> > Hi Andrew,

>> > ----- Mail original -----
>> > > De: "Andrew Haley" < [ mailto:aph at redhat.com | aph at redhat.com ] >
>>> > À: "Zheka Kozlov" < [ mailto:orionllmain at gmail.com | orionllmain at gmail.com ] >,
>> > > "Martijn Verburg" <
>> > [ mailto:martijnverburg at gmail.com | martijnverburg at gmail.com ] >
>> > > Cc: "jdk-dev" < [ mailto:jdk-dev at openjdk.java.net | 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.


>> Oh, do Google's coding conventions really mandate this practice? I've had a
>> look through the Google Java Style guide, but I can't seem to find anything
>> to confirm it. Do you have a source that I can check?


>> > 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/ | https://www.redhat.com ] >
>> > > EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671

>> > cheers,
>> > Rémi


>> Cheers,
>> Jonathan