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

[Jeremy Manson]

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*link*
> <http://go/java-practices/final#params_locals>*mode_edit*
> <https://cs.corp.google.com/#piper///depot/eng/doc/devguide/java/practices/final.md&edit=1&l=76>
> *comment*
> <https://engdoc.corp.google.com/eng/doc/devguide/java/practices/final.md?cl=head#>
>
> 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 blank final
> <https://en.wikipedia.org/wiki/Final_(Java)#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 opt in
> <http://go/errorprone/bugpatterns#optional> to @Var Error Prone
> enforcement <http://errorprone.info/bugpattern/Var>. 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 <
jbluettduncan at gmail.com> wrote:

> Hi Rémi,
>
> You may find my (short) response inline.
>
> On 28 January 2018 at 23:47, Remi Forax <forax at univ-mlv.fr> wrote:
>
> > 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.
> >
>
> 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>
> > > EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671
> >
> > cheers,
> > Rémi
> >
>
> Cheers,
> Jonathan
>