Re: Unnecessary uses of final on local variables

[Kirk Lund]

Just to *wrap up* this thread: *I'm with-drawing my proposal.*

We do not have any sort of consensus (rough or otherwise) regarding the use
of final on local variables.

Thanks to everyone who participated!

On Thu, Jun 13, 2019 at 1:31 PM Kirk Lund  wrote:

> According to Effective Java 3rd Edition, all local variables are
> implicitly made final by the JVM (and thus receiving the same JVM
> optimizations as a final variable) without requiring use of the keyword
> as long as you only set the value once. So this becomes an unnecessary use
> of the keyword final which really just adds noise to the code (one more
> word on many lines) much like unnecessary uses of this. on references to
> class fields. The only context where it's still valuable to use final is
> on class fields and constants where it provides concurrency guarantees.
>
> It may be useful to temporarily mark a local variable as final while
> performing a refactoring. See Martin Fowler's book for various refactorings
> in which he does this.
>
> There really is no value in retaining the keyword on a local variable any
> longer, so I think we should avoid using it in the same way we avoid
> unnecessary uses of this. on references to class fields. It's all just
> more noise in the code.
>
>

Re: Unnecessary uses of final on local variables

[Kirk Lund]

Thanks for the very thoughtful and well-worded reply, Bill. I would
certainly welcome further discussion on how and where to consistently use
the final keyword (if that's desirable), especially within the context of
reviewing pull requests.

On Wed, Jun 19, 2019 at 11:23 AM Bill Burcham  wrote:

> -1 to the proposal as I understand it:
>
> Premise:
>
> a. Because the "final" modifier on local variables serves no function other
> than to inform compiler optimization and…
>
> b. because the compiler can tell if a variable is "effectively final"
> without an explicit "final" modifier in the source code
>
> Conclusion:
>
> • The "final" modifier is just "noise" in the source code, so…
>
> Ramifications:
>
> 1. Do not use the "final" modifier on local variables.
>
> 2. By extension, it would be not just ok, but in fact a positive change, to
> _remove_ the "final" keyword from local variables, because it is just
> noise.
>
> 3. I believe the proposal should be interpreted to apply to method
> parameters as well—not just local variables. (Local variables includes loop
> variables when using for-each syntax—those can potentially be declared
> "final" just like any other local variable).
>
>
> I am thumbs-down on the proposal, first, because I believe the premise of
> the proposal is flawed. If the only value of the "final" modifier on
> storage was compile-time optimization then my view might be different. The
> fact is that the "final" modifier on a variable (or for-each loop variable)
> or method parameter declaration expresses the developer's intention that
> the value not be modified after initialization. Any violation of that
> intention will be flagged and rejected by the compiler. As such, the
> "final" modifier on variable and method parameter declarations is part of
> our arsenal of Java language constructs, such as types (including generic
> types), that let us express our intentions to the compiler.
>
> Lurking in the proposal is a danger (ramification (2)): that some of us
> will think it's not only ok, but an _improvement_ to actively _remove_
> final modifiers from local variable declarations, parameter declarations
> and for-each loop variable declarations. This lurking danger is a clear and
> present threat which I feel requires urgent consensus.
>
> I, for one, put "final" where I mean to put "final". I shouldn't have to
> monitor every single PR to ensure my finals aren't removed as noise—any
> more than I should have to monitor PRs to ensure folks aren't turning
> List back into (pre-generic) List.
>
> Can we at least agree to this:
>
> • when we encounter a final local variable, method parameter, or for-each
> loop variable declaration, we agree to _not_ remove the final modifier
> unless we have to
>
> And by "have to", I mean, we actually need to mutate the variable to make
> the code work. Any aesthetic concern about "final" being "noise" would not
> count here.
>
> -Bill
>

Re: Unnecessary uses of final on local variables

[Bill Burcham]

-1 to the proposal as I understand it:

Premise:

a. Because the "final" modifier on local variables serves no function other
than to inform compiler optimization and…

b. because the compiler can tell if a variable is "effectively final"
without an explicit "final" modifier in the source code

Conclusion:

• The "final" modifier is just "noise" in the source code, so…

Ramifications:

1. Do not use the "final" modifier on local variables.

2. By extension, it would be not just ok, but in fact a positive change, to
_remove_ the "final" keyword from local variables, because it is just noise.

3. I believe the proposal should be interpreted to apply to method
parameters as well—not just local variables. (Local variables includes loop
variables when using for-each syntax—those can potentially be declared
"final" just like any other local variable).


I am thumbs-down on the proposal, first, because I believe the premise of
the proposal is flawed. If the only value of the "final" modifier on
storage was compile-time optimization then my view might be different. The
fact is that the "final" modifier on a variable (or for-each loop variable)
or method parameter declaration expresses the developer's intention that
the value not be modified after initialization. Any violation of that
intention will be flagged and rejected by the compiler. As such, the
"final" modifier on variable and method parameter declarations is part of
our arsenal of Java language constructs, such as types (including generic
types), that let us express our intentions to the compiler.

Lurking in the proposal is a danger (ramification (2)): that some of us
will think it's not only ok, but an _improvement_ to actively _remove_
final modifiers from local variable declarations, parameter declarations
and for-each loop variable declarations. This lurking danger is a clear and
present threat which I feel requires urgent consensus.

I, for one, put "final" where I mean to put "final". I shouldn't have to
monitor every single PR to ensure my finals aren't removed as noise—any
more than I should have to monitor PRs to ensure folks aren't turning
List back into (pre-generic) List.

Can we at least agree to this:

• when we encounter a final local variable, method parameter, or for-each
loop variable declaration, we agree to _not_ remove the final modifier
unless we have to

And by "have to", I mean, we actually need to mutate the variable to make
the code work. Any aesthetic concern about "final" being "noise" would not
count here.

-Bill

Re: Unnecessary uses of final on local variables

[Udo Kohlmeyer]

I agree with Darrel, Bill has made some very compelling arguments.

I also add my vote of -1 to remove "noisy" final keywords from local 
variables.


I am VERY interested in understanding how the JVM would handle this, as 
final is a keyword that stops the reassignment of the variable with 
another value. It would never stop immutability concerns. This can only 
be achieved by following stricter rules regarding how Pojos are created 
and coding practices.


I believe it is better to be more secure and opt-out when not required, 
than trying to add-in being more secure (as you are more likely to miss 
things).


--Udo

On 6/19/19 08:41, Darrel Schneider wrote:

I find Bill's argument of using final by default on everything convincing
and removing it when you have something that needs to be changed.
It is not in keeping with my current practice but I'm willing to change.
So I vote -1 to not using "final" on local variables.


On Wed, Jun 19, 2019 at 7:29 AM Anthony Baker  wrote:


Just to confirm, the primary place where we make project decisions is on
the dev@geode list.  Thanks!

Anthony



On Jun 19, 2019, at 7:19 AM, Bill Burcham  wrote:

I feel that a lot more
conversation is needed, outside email. On the other hand, this mailing

list

is a fine place to deliberate. But to deliberate successfully on this
issue, via email, I think we'll have to break it down further, and we'll
have to be comfortable with the process taking a long time.

Re: Unnecessary uses of final on local variables

[Darrel Schneider]

I find Bill's argument of using final by default on everything convincing
and removing it when you have something that needs to be changed.
It is not in keeping with my current practice but I'm willing to change.
So I vote -1 to not using "final" on local variables.


On Wed, Jun 19, 2019 at 7:29 AM Anthony Baker  wrote:

> Just to confirm, the primary place where we make project decisions is on
> the dev@geode list.  Thanks!
>
> Anthony
>
>
> > On Jun 19, 2019, at 7:19 AM, Bill Burcham  wrote:
> >
> > I feel that a lot more
> > conversation is needed, outside email. On the other hand, this mailing
> list
> > is a fine place to deliberate. But to deliberate successfully on this
> > issue, via email, I think we'll have to break it down further, and we'll
> > have to be comfortable with the process taking a long time.
>
>

Re: Unnecessary uses of final on local variables

[Anthony Baker]

Just to confirm, the primary place where we make project decisions is on the 
dev@geode list.  Thanks!

Anthony


> On Jun 19, 2019, at 7:19 AM, Bill Burcham  wrote:
> 
> I feel that a lot more
> conversation is needed, outside email. On the other hand, this mailing list
> is a fine place to deliberate. But to deliberate successfully on this
> issue, via email, I think we'll have to break it down further, and we'll
> have to be comfortable with the process taking a long time.

Re: Unnecessary uses of final on local variables

[Bill Burcham]

Shorter methods are better! Code is indeed better when it's understandable
in smaller chunks.

The reason shorter methods are better is because there is less you have to
hold in your mind when evaluating them. That's why I make fields, method
parameters, and local variables final by default—when final is the default
for those, I don't have to wonder, at some point in the code, whether they
have changed. Non-final variables stand out in stark relief.

Murtuza's point that "final in Java does not guarantee immutability" is
true on its face. What the final modifier does on a field/variable
declaration is ensure that the primitive value or reference is immutable.
Yes you can still construct classes whose instances are mutable because you
can choose to make one or more fields not final. But there is great value
in declaring your intention not to mutate certain fields/variables.
Declaring that intention lets you use the compiler to check that your
intentions are not violated.

I'm happy we have started this discussion, but from the magnitude of
divergence in the responses, this email thread seems like the wrong time
and place to lock down a group decision. I feel that a lot more
conversation is needed, outside email. On the other hand, this mailing list
is a fine place to deliberate. But to deliberate successfully on this
issue, via email, I think we'll have to break it down further, and we'll
have to be comfortable with the process taking a long time.

On Tue, Jun 18, 2019 at 3:23 PM Owen Nichols  wrote:

> I recommend:
> * Use final if you want to
> * Don’t -1 someone’s PR because they did or didn’t use final.
>
>
> Personally, there is one case where I like to use final on a local
> variable: forcing the compiler to tell me if I’ve covered all code paths.
> Here’s a very simple example:
>
> final int x;
> if (cond) {
>   x = 1;
> }
> else if(othercond) {
>  x = 2;
> }
>
> //this will fail to compile because there is still one codepath where x
> never gets initialized.
>
> Without final, you might be temped to write it more compactly as:
>
> int x = 2;
> if (cond) {
>   x = 1;
> }
>
> //in this case, instead of a compiler error, you get a very subtle bug.
> Let the compiler work for you whenever possible!
>
> This strategy is also handy if you’re initializing a variable with a
> switch statements, because the final declaration will protect you from
> missing break statements.
>
> > On Jun 18, 2019, at 3:02 PM, Murtuza Boxwala 
> wrote:
> >
> > What does "rough consensus"[1] look like on this thread? How do we make
> a decision and close it out?
> >
> > Kirk suggested an idea, there’s been a couple days of feedback, so we
> can:
> >
> > 1) reject the proposal and commit to using final ‘everywhere'
> > 2) accept the proposal and use final very sparingly
> > 3) continue the discussion over e-mail
> > 4) take other steps to come to a consensus like
> >   have a meeting with a few folks who are passionate about the topic
> >Try both approaches.  Pick one module and use final everywhere,
> and pick another and use it sparingly and see which approach we like
> >
> >
> > Personally, I don’t see any “fundamental flaws"[1] with using final or
> removing it.
> >
> >
> > Also, I might just be rushing the natural flow of conversation, so in
> that case, sorry for being impatient.
> >
> > 1-https://doist.com/blog/decision-making-flat-organization/ <
> https://doist.com/blog/decision-making-flat-organization/>
> >
> >> On Jun 18, 2019, at 2:48 PM, Jinmei Liao  wrote:
> >>
> >> I agree with Murtuza, most finals on local variables and method
> parameters
> >> are just noise to me. I only use "final" on these two situations:
> >> 1. to declare public static constants of immutable types (e.g. String,
> >> Integer)
> >> 2. to prevent children from overriding a method.
> >>
> >> But thought I can't offer an example, I don't want to put out a blank
> >> statement saying that "final" on local variables are entirely
> unnecessary.
> >> There must be a case that it could be useful, so even if we come to a
> >> consensus that local variables should not have final on it, I don't
> think
> >> using a static analysis tool to get rid of all of them is a good idea.
> >>
> >> On Tue, Jun 18, 2019 at 11:14 AM Anthony Baker 
> wrote:
> >>
> >>> I’ll offer this alternative:  perhaps shorter method bodies obviate the
> >>> need for explicit final vars.
> >>>
> >>> Anthony
> >>>
> >>>
>  On Jun 18, 2019, at 10:30 AM, Ernest Burghardt  >
> >>> wrote:
> 
>  +1 to auto-enforcement (if possible) post-consensus
> 
>  On Tue, Jun 18, 2019 at 8:33 AM Murtuza Boxwala 
> >>> wrote:
> 
> > final in Java does not guarantee immutability.  It would be AWESOME
> if
> >>> it
> > did but all it guarantees is that the variable cannot be reassigned.
> In
> > most cases the variable points to an object’s location (memory
> >>> address), so
> > you can still call methods on it, e.g.
> >
> > final var = new 

Re: Unnecessary uses of final on local variables

[Owen Nichols]

I recommend:
* Use final if you want to
* Don’t -1 someone’s PR because they did or didn’t use final.


Personally, there is one case where I like to use final on a local variable: 
forcing the compiler to tell me if I’ve covered all code paths.  Here’s a very 
simple example:

final int x;
if (cond) {
  x = 1;
}
else if(othercond) {
 x = 2;
}

//this will fail to compile because there is still one codepath where x never 
gets initialized.

Without final, you might be temped to write it more compactly as:

int x = 2;
if (cond) {
  x = 1;
}

//in this case, instead of a compiler error, you get a very subtle bug.  Let 
the compiler work for you whenever possible!

This strategy is also handy if you’re initializing a variable with a switch 
statements, because the final declaration will protect you from missing break 
statements.

> On Jun 18, 2019, at 3:02 PM, Murtuza Boxwala  wrote:
> 
> What does "rough consensus"[1] look like on this thread? How do we make a 
> decision and close it out?
> 
> Kirk suggested an idea, there’s been a couple days of feedback, so we can:
> 
> 1) reject the proposal and commit to using final ‘everywhere'
> 2) accept the proposal and use final very sparingly
> 3) continue the discussion over e-mail
> 4) take other steps to come to a consensus like
>   have a meeting with a few folks who are passionate about the topic
>Try both approaches.  Pick one module and use final everywhere, and 
> pick another and use it sparingly and see which approach we like
> 
> 
> Personally, I don’t see any “fundamental flaws"[1] with using final or 
> removing it.
> 
> 
> Also, I might just be rushing the natural flow of conversation, so in that 
> case, sorry for being impatient.
> 
> 1-https://doist.com/blog/decision-making-flat-organization/ 
> 
> 
>> On Jun 18, 2019, at 2:48 PM, Jinmei Liao  wrote:
>> 
>> I agree with Murtuza, most finals on local variables and method parameters
>> are just noise to me. I only use "final" on these two situations:
>> 1. to declare public static constants of immutable types (e.g. String,
>> Integer)
>> 2. to prevent children from overriding a method.
>> 
>> But thought I can't offer an example, I don't want to put out a blank
>> statement saying that "final" on local variables are entirely unnecessary.
>> There must be a case that it could be useful, so even if we come to a
>> consensus that local variables should not have final on it, I don't think
>> using a static analysis tool to get rid of all of them is a good idea.
>> 
>> On Tue, Jun 18, 2019 at 11:14 AM Anthony Baker  wrote:
>> 
>>> I’ll offer this alternative:  perhaps shorter method bodies obviate the
>>> need for explicit final vars.
>>> 
>>> Anthony
>>> 
>>> 
 On Jun 18, 2019, at 10:30 AM, Ernest Burghardt 
>>> wrote:
 
 +1 to auto-enforcement (if possible) post-consensus
 
 On Tue, Jun 18, 2019 at 8:33 AM Murtuza Boxwala 
>>> wrote:
 
> final in Java does not guarantee immutability.  It would be AWESOME if
>>> it
> did but all it guarantees is that the variable cannot be reassigned. In
> most cases the variable points to an object’s location (memory
>>> address), so
> you can still call methods on it, e.g.
> 
> final var = new Foo();
> var.mutateState();
> 
> final variables like these are in no way thread safe. To make objects
> immutable, the objects themselves need to follow a pattern that
>>> guarantees
> that.  Something like the ValueObject <
> https://martinfowler.com/bliki/ValueObject.html> pattern.
> 
> Mutability may well be the enemy, but I don’t think this is the
>>> construct
> that gets us much/if any closer.
> 
> In local variables and parameters final feels like noise to me, and in
> fact may make things more difficult to reason about, if we start
>>> assuming
> variables with final are thread safe.
> 
> But I may be missing something.  I am more curious to see how we come to
> consensus on something like this, because the worst outcome from all
>>> this
> will be to have some folks actively adding final and some actively
>>> removing
> it, which will add noise to PRs and to the code.  And once we reach
> consensus, how do we enforce somethings like this? ./gradlew spA?
> 
>> On Jun 17, 2019, at 8:55 PM, Jacob Barrett 
>>> wrote:
>> 
>> I too am in camp final too. You could say `final boolean useFinal =
> true`. For all the same reasons Bill stated below.
>> 
>>> On Jun 17, 2019, at 5:33 PM, Bill Burcham 
>>> wrote:
>>> 
>>> The final keyword is not redundant—quite the opposite—it's extremely
> valuable.
>>> 
>>> Local variables are not, in general, final, unless you declare them as
> such. That being the case, it is not redundant to declare local
>>> variables
> "final".
>>> 
>>> What the compiler will do for you, is _if_ it can 

Re: Unnecessary uses of final on local variables

[Udo Kohlmeyer]

+1 to everything Bill said

+1 to what Anthony recommended

I think that we in many cases we should not confuse scope with variable 
reassignment.


And we should not confuse variable reassignment with methods that affect 
change of a local object. Stateful objects don't have to be immutable 
and usually are not.. But good practices (wrt threading) dictate that we 
should prefer immutability over local object state changes.


I vote for Object fields to be final from construction and I vote for 
method parameters to be final. AND because I love Kotlin I vote for 
classes to be final and not open for extension without real cause.


But this is not what this thread is about

So.. imo, does it really matter if a developer was more cautious by 
adding final to all their local variable declarations? It is a little 
more defensive, but at the end of the day, it makes for better code... imo.


--Udo

On 6/18/19 11:48, Jinmei Liao wrote:

I agree with Murtuza, most finals on local variables and method parameters
are just noise to me. I only use "final" on these two situations:
1. to declare public static constants of immutable types (e.g. String,
Integer)
2. to prevent children from overriding a method.

But thought I can't offer an example, I don't want to put out a blank
statement saying that "final" on local variables are entirely unnecessary.
There must be a case that it could be useful, so even if we come to a
consensus that local variables should not have final on it, I don't think
using a static analysis tool to get rid of all of them is a good idea.

On Tue, Jun 18, 2019 at 11:14 AM Anthony Baker  wrote:


I’ll offer this alternative:  perhaps shorter method bodies obviate the
need for explicit final vars.

Anthony



On Jun 18, 2019, at 10:30 AM, Ernest Burghardt 

wrote:

+1 to auto-enforcement (if possible) post-consensus

On Tue, Jun 18, 2019 at 8:33 AM Murtuza Boxwala 

wrote:

final in Java does not guarantee immutability.  It would be AWESOME if

it

did but all it guarantees is that the variable cannot be reassigned. In
most cases the variable points to an object’s location (memory

address), so

you can still call methods on it, e.g.

final var = new Foo();
var.mutateState();

final variables like these are in no way thread safe. To make objects
immutable, the objects themselves need to follow a pattern that

guarantees

that.  Something like the ValueObject <
https://martinfowler.com/bliki/ValueObject.html> pattern.

Mutability may well be the enemy, but I don’t think this is the

construct

that gets us much/if any closer.

In local variables and parameters final feels like noise to me, and in
fact may make things more difficult to reason about, if we start

assuming

variables with final are thread safe.

But I may be missing something.  I am more curious to see how we come to
consensus on something like this, because the worst outcome from all

this

will be to have some folks actively adding final and some actively

removing

it, which will add noise to PRs and to the code.  And once we reach
consensus, how do we enforce somethings like this? ./gradlew spA?


On Jun 17, 2019, at 8:55 PM, Jacob Barrett 

wrote:

I too am in camp final too. You could say `final boolean useFinal =

true`. For all the same reasons Bill stated below.

On Jun 17, 2019, at 5:33 PM, Bill Burcham 

wrote:

The final keyword is not redundant—quite the opposite—it's extremely

valuable.

Local variables are not, in general, final, unless you declare them as

such. That being the case, it is not redundant to declare local

variables

"final".

What the compiler will do for you, is _if_ it can ensure that a local

variable (or method parameter) is never modified (after initialization)
then that variable is treated as "effectively final". Variables that are
explicitly declared final, or are determined to be "effectively final"

may

be referenced in lambdas. That's a nice thing.

I would like to offer a counter-recommendation: final should be the

default everywhere for fields, for method parameters (on classes, not on
interfaces), and for local variables.

Many benefits would accrue to us, should we adopt this default:

1. final fields must be initialized in a constructor and never mutated

again. This makes reasoning about those fields easier.

2. classes that have all their fields final are immutable and hence

easier to reason about: they can be passed between threads, for

instance,

with no need to protect from races

3. final method parameters can never be mutated, making them easier to

reason about

4. final local variables can never be mutated, making them easier to

reason about

When final is the rule, non-final is the exception. Another way of

saying that is that when final is the rule, mutability is the exception.
That is as it should be. Mutability is the enemy.

I have turned on a couple IntelliJ settings that make this the default

for me. I encourage you to do the same:

First there are these two 

Re: Unnecessary uses of final on local variables

[Murtuza Boxwala]

What does "rough consensus"[1] look like on this thread? How do we make a 
decision and close it out?

Kirk suggested an idea, there’s been a couple days of feedback, so we can:

1) reject the proposal and commit to using final ‘everywhere'
2) accept the proposal and use final very sparingly
3) continue the discussion over e-mail
4) take other steps to come to a consensus like
have a meeting with a few folks who are passionate about the topic
Try both approaches.  Pick one module and use final everywhere, and 
pick another and use it sparingly and see which approach we like


Personally, I don’t see any “fundamental flaws"[1] with using final or removing 
it.


Also, I might just be rushing the natural flow of conversation, so in that 
case, sorry for being impatient.

1-https://doist.com/blog/decision-making-flat-organization/ 


> On Jun 18, 2019, at 2:48 PM, Jinmei Liao  wrote:
> 
> I agree with Murtuza, most finals on local variables and method parameters
> are just noise to me. I only use "final" on these two situations:
> 1. to declare public static constants of immutable types (e.g. String,
> Integer)
> 2. to prevent children from overriding a method.
> 
> But thought I can't offer an example, I don't want to put out a blank
> statement saying that "final" on local variables are entirely unnecessary.
> There must be a case that it could be useful, so even if we come to a
> consensus that local variables should not have final on it, I don't think
> using a static analysis tool to get rid of all of them is a good idea.
> 
> On Tue, Jun 18, 2019 at 11:14 AM Anthony Baker  wrote:
> 
>> I’ll offer this alternative:  perhaps shorter method bodies obviate the
>> need for explicit final vars.
>> 
>> Anthony
>> 
>> 
>>> On Jun 18, 2019, at 10:30 AM, Ernest Burghardt 
>> wrote:
>>> 
>>> +1 to auto-enforcement (if possible) post-consensus
>>> 
>>> On Tue, Jun 18, 2019 at 8:33 AM Murtuza Boxwala 
>> wrote:
>>> 
 final in Java does not guarantee immutability.  It would be AWESOME if
>> it
 did but all it guarantees is that the variable cannot be reassigned. In
 most cases the variable points to an object’s location (memory
>> address), so
 you can still call methods on it, e.g.
 
 final var = new Foo();
 var.mutateState();
 
 final variables like these are in no way thread safe. To make objects
 immutable, the objects themselves need to follow a pattern that
>> guarantees
 that.  Something like the ValueObject <
 https://martinfowler.com/bliki/ValueObject.html> pattern.
 
 Mutability may well be the enemy, but I don’t think this is the
>> construct
 that gets us much/if any closer.
 
 In local variables and parameters final feels like noise to me, and in
 fact may make things more difficult to reason about, if we start
>> assuming
 variables with final are thread safe.
 
 But I may be missing something.  I am more curious to see how we come to
 consensus on something like this, because the worst outcome from all
>> this
 will be to have some folks actively adding final and some actively
>> removing
 it, which will add noise to PRs and to the code.  And once we reach
 consensus, how do we enforce somethings like this? ./gradlew spA?
 
> On Jun 17, 2019, at 8:55 PM, Jacob Barrett 
>> wrote:
> 
> I too am in camp final too. You could say `final boolean useFinal =
 true`. For all the same reasons Bill stated below.
> 
>> On Jun 17, 2019, at 5:33 PM, Bill Burcham 
>> wrote:
>> 
>> The final keyword is not redundant—quite the opposite—it's extremely
 valuable.
>> 
>> Local variables are not, in general, final, unless you declare them as
 such. That being the case, it is not redundant to declare local
>> variables
 "final".
>> 
>> What the compiler will do for you, is _if_ it can ensure that a local
 variable (or method parameter) is never modified (after initialization)
 then that variable is treated as "effectively final". Variables that are
 explicitly declared final, or are determined to be "effectively final"
>> may
 be referenced in lambdas. That's a nice thing.
>> 
>> I would like to offer a counter-recommendation: final should be the
 default everywhere for fields, for method parameters (on classes, not on
 interfaces), and for local variables.
>> 
>> Many benefits would accrue to us, should we adopt this default:
>> 
>> 1. final fields must be initialized in a constructor and never mutated
 again. This makes reasoning about those fields easier.
>> 2. classes that have all their fields final are immutable and hence
 easier to reason about: they can be passed between threads, for
>> instance,
 with no need to protect from races
>> 3. final method parameters can never be mutated, making them easier to
 

Re: Unnecessary uses of final on local variables

[Jinmei Liao]

I agree with Murtuza, most finals on local variables and method parameters
are just noise to me. I only use "final" on these two situations:
1. to declare public static constants of immutable types (e.g. String,
Integer)
2. to prevent children from overriding a method.

But thought I can't offer an example, I don't want to put out a blank
statement saying that "final" on local variables are entirely unnecessary.
There must be a case that it could be useful, so even if we come to a
consensus that local variables should not have final on it, I don't think
using a static analysis tool to get rid of all of them is a good idea.

On Tue, Jun 18, 2019 at 11:14 AM Anthony Baker  wrote:

> I’ll offer this alternative:  perhaps shorter method bodies obviate the
> need for explicit final vars.
>
> Anthony
>
>
> > On Jun 18, 2019, at 10:30 AM, Ernest Burghardt 
> wrote:
> >
> > +1 to auto-enforcement (if possible) post-consensus
> >
> > On Tue, Jun 18, 2019 at 8:33 AM Murtuza Boxwala 
> wrote:
> >
> >> final in Java does not guarantee immutability.  It would be AWESOME if
> it
> >> did but all it guarantees is that the variable cannot be reassigned. In
> >> most cases the variable points to an object’s location (memory
> address), so
> >> you can still call methods on it, e.g.
> >>
> >> final var = new Foo();
> >> var.mutateState();
> >>
> >> final variables like these are in no way thread safe. To make objects
> >> immutable, the objects themselves need to follow a pattern that
> guarantees
> >> that.  Something like the ValueObject <
> >> https://martinfowler.com/bliki/ValueObject.html> pattern.
> >>
> >> Mutability may well be the enemy, but I don’t think this is the
> construct
> >> that gets us much/if any closer.
> >>
> >> In local variables and parameters final feels like noise to me, and in
> >> fact may make things more difficult to reason about, if we start
> assuming
> >> variables with final are thread safe.
> >>
> >> But I may be missing something.  I am more curious to see how we come to
> >> consensus on something like this, because the worst outcome from all
> this
> >> will be to have some folks actively adding final and some actively
> removing
> >> it, which will add noise to PRs and to the code.  And once we reach
> >> consensus, how do we enforce somethings like this? ./gradlew spA?
> >>
> >>> On Jun 17, 2019, at 8:55 PM, Jacob Barrett 
> wrote:
> >>>
> >>> I too am in camp final too. You could say `final boolean useFinal =
> >> true`. For all the same reasons Bill stated below.
> >>>
>  On Jun 17, 2019, at 5:33 PM, Bill Burcham 
> wrote:
> 
>  The final keyword is not redundant—quite the opposite—it's extremely
> >> valuable.
> 
>  Local variables are not, in general, final, unless you declare them as
> >> such. That being the case, it is not redundant to declare local
> variables
> >> "final".
> 
>  What the compiler will do for you, is _if_ it can ensure that a local
> >> variable (or method parameter) is never modified (after initialization)
> >> then that variable is treated as "effectively final". Variables that are
> >> explicitly declared final, or are determined to be "effectively final"
> may
> >> be referenced in lambdas. That's a nice thing.
> 
>  I would like to offer a counter-recommendation: final should be the
> >> default everywhere for fields, for method parameters (on classes, not on
> >> interfaces), and for local variables.
> 
>  Many benefits would accrue to us, should we adopt this default:
> 
>  1. final fields must be initialized in a constructor and never mutated
> >> again. This makes reasoning about those fields easier.
>  2. classes that have all their fields final are immutable and hence
> >> easier to reason about: they can be passed between threads, for
> instance,
> >> with no need to protect from races
>  3. final method parameters can never be mutated, making them easier to
> >> reason about
>  4. final local variables can never be mutated, making them easier to
> >> reason about
> 
>  When final is the rule, non-final is the exception. Another way of
> >> saying that is that when final is the rule, mutability is the exception.
> >> That is as it should be. Mutability is the enemy.
> 
>  I have turned on a couple IntelliJ settings that make this the default
> >> for me. I encourage you to do the same:
> 
>  First there are these two "Code style issues" in the Java inspections:
> 
>  "Field may be 'final'"
>  "Local variable or parameter can be final"
> 
> 
> 
>  Then there is this setting will cause newly-defined variables created
> >> via the "Extract variable" refactoring:
> 
>  If you select that check box (after selecting those inspections
> >> settings above), it'll declare the newly-introduced variable "final" and
> >> it'll remember the setting the next time you invoke "Extract variable"
> >> refactoring
> 
> 
> >>
> >>
>
>

Re: Unnecessary uses of final on local variables

[Anthony Baker]

I’ll offer this alternative:  perhaps shorter method bodies obviate the need 
for explicit final vars.

Anthony


> On Jun 18, 2019, at 10:30 AM, Ernest Burghardt  wrote:
> 
> +1 to auto-enforcement (if possible) post-consensus
> 
> On Tue, Jun 18, 2019 at 8:33 AM Murtuza Boxwala  wrote:
> 
>> final in Java does not guarantee immutability.  It would be AWESOME if it
>> did but all it guarantees is that the variable cannot be reassigned. In
>> most cases the variable points to an object’s location (memory address), so
>> you can still call methods on it, e.g.
>> 
>> final var = new Foo();
>> var.mutateState();
>> 
>> final variables like these are in no way thread safe. To make objects
>> immutable, the objects themselves need to follow a pattern that guarantees
>> that.  Something like the ValueObject <
>> https://martinfowler.com/bliki/ValueObject.html> pattern.
>> 
>> Mutability may well be the enemy, but I don’t think this is the construct
>> that gets us much/if any closer.
>> 
>> In local variables and parameters final feels like noise to me, and in
>> fact may make things more difficult to reason about, if we start assuming
>> variables with final are thread safe.
>> 
>> But I may be missing something.  I am more curious to see how we come to
>> consensus on something like this, because the worst outcome from all this
>> will be to have some folks actively adding final and some actively removing
>> it, which will add noise to PRs and to the code.  And once we reach
>> consensus, how do we enforce somethings like this? ./gradlew spA?
>> 
>>> On Jun 17, 2019, at 8:55 PM, Jacob Barrett  wrote:
>>> 
>>> I too am in camp final too. You could say `final boolean useFinal =
>> true`. For all the same reasons Bill stated below.
>>> 
 On Jun 17, 2019, at 5:33 PM, Bill Burcham  wrote:
 
 The final keyword is not redundant—quite the opposite—it's extremely
>> valuable.
 
 Local variables are not, in general, final, unless you declare them as
>> such. That being the case, it is not redundant to declare local variables
>> "final".
 
 What the compiler will do for you, is _if_ it can ensure that a local
>> variable (or method parameter) is never modified (after initialization)
>> then that variable is treated as "effectively final". Variables that are
>> explicitly declared final, or are determined to be "effectively final" may
>> be referenced in lambdas. That's a nice thing.
 
 I would like to offer a counter-recommendation: final should be the
>> default everywhere for fields, for method parameters (on classes, not on
>> interfaces), and for local variables.
 
 Many benefits would accrue to us, should we adopt this default:
 
 1. final fields must be initialized in a constructor and never mutated
>> again. This makes reasoning about those fields easier.
 2. classes that have all their fields final are immutable and hence
>> easier to reason about: they can be passed between threads, for instance,
>> with no need to protect from races
 3. final method parameters can never be mutated, making them easier to
>> reason about
 4. final local variables can never be mutated, making them easier to
>> reason about
 
 When final is the rule, non-final is the exception. Another way of
>> saying that is that when final is the rule, mutability is the exception.
>> That is as it should be. Mutability is the enemy.
 
 I have turned on a couple IntelliJ settings that make this the default
>> for me. I encourage you to do the same:
 
 First there are these two "Code style issues" in the Java inspections:
 
 "Field may be 'final'"
 "Local variable or parameter can be final"
 
 
 
 Then there is this setting will cause newly-defined variables created
>> via the "Extract variable" refactoring:
 
 If you select that check box (after selecting those inspections
>> settings above), it'll declare the newly-introduced variable "final" and
>> it'll remember the setting the next time you invoke "Extract variable"
>> refactoring
 
 
>> 
>> 

Re: Unnecessary uses of final on local variables

[Ernest Burghardt]

+1 to auto-enforcement (if possible) post-consensus

On Tue, Jun 18, 2019 at 8:33 AM Murtuza Boxwala  wrote:

> final in Java does not guarantee immutability.  It would be AWESOME if it
> did but all it guarantees is that the variable cannot be reassigned. In
> most cases the variable points to an object’s location (memory address), so
> you can still call methods on it, e.g.
>
> final var = new Foo();
> var.mutateState();
>
> final variables like these are in no way thread safe. To make objects
> immutable, the objects themselves need to follow a pattern that guarantees
> that.  Something like the ValueObject <
> https://martinfowler.com/bliki/ValueObject.html> pattern.
>
> Mutability may well be the enemy, but I don’t think this is the construct
> that gets us much/if any closer.
>
> In local variables and parameters final feels like noise to me, and in
> fact may make things more difficult to reason about, if we start assuming
> variables with final are thread safe.
>
> But I may be missing something.  I am more curious to see how we come to
> consensus on something like this, because the worst outcome from all this
> will be to have some folks actively adding final and some actively removing
> it, which will add noise to PRs and to the code.  And once we reach
> consensus, how do we enforce somethings like this? ./gradlew spA?
>
> > On Jun 17, 2019, at 8:55 PM, Jacob Barrett  wrote:
> >
> > I too am in camp final too. You could say `final boolean useFinal =
> true`. For all the same reasons Bill stated below.
> >
> >> On Jun 17, 2019, at 5:33 PM, Bill Burcham  wrote:
> >>
> >> The final keyword is not redundant—quite the opposite—it's extremely
> valuable.
> >>
> >> Local variables are not, in general, final, unless you declare them as
> such. That being the case, it is not redundant to declare local variables
> "final".
> >>
> >> What the compiler will do for you, is _if_ it can ensure that a local
> variable (or method parameter) is never modified (after initialization)
> then that variable is treated as "effectively final". Variables that are
> explicitly declared final, or are determined to be "effectively final" may
> be referenced in lambdas. That's a nice thing.
> >>
> >> I would like to offer a counter-recommendation: final should be the
> default everywhere for fields, for method parameters (on classes, not on
> interfaces), and for local variables.
> >>
> >> Many benefits would accrue to us, should we adopt this default:
> >>
> >> 1. final fields must be initialized in a constructor and never mutated
> again. This makes reasoning about those fields easier.
> >> 2. classes that have all their fields final are immutable and hence
> easier to reason about: they can be passed between threads, for instance,
> with no need to protect from races
> >> 3. final method parameters can never be mutated, making them easier to
> reason about
> >> 4. final local variables can never be mutated, making them easier to
> reason about
> >>
> >> When final is the rule, non-final is the exception. Another way of
> saying that is that when final is the rule, mutability is the exception.
> That is as it should be. Mutability is the enemy.
> >>
> >> I have turned on a couple IntelliJ settings that make this the default
> for me. I encourage you to do the same:
> >>
> >> First there are these two "Code style issues" in the Java inspections:
> >>
> >> "Field may be 'final'"
> >> "Local variable or parameter can be final"
> >>
> >>
> >>
> >> Then there is this setting will cause newly-defined variables created
> via the "Extract variable" refactoring:
> >>
> >> If you select that check box (after selecting those inspections
> settings above), it'll declare the newly-introduced variable "final" and
> it'll remember the setting the next time you invoke "Extract variable"
> refactoring
> >>
> >>
>
>

Re: Unnecessary uses of final on local variables

[Murtuza Boxwala]

final in Java does not guarantee immutability.  It would be AWESOME if it did 
but all it guarantees is that the variable cannot be reassigned. In most cases 
the variable points to an object’s location (memory address), so you can still 
call methods on it, e.g.

final var = new Foo();
var.mutateState();

final variables like these are in no way thread safe. To make objects 
immutable, the objects themselves need to follow a pattern that guarantees 
that.  Something like the ValueObject 
 pattern.

Mutability may well be the enemy, but I don’t think this is the construct that 
gets us much/if any closer.

In local variables and parameters final feels like noise to me, and in fact may 
make things more difficult to reason about, if we start assuming variables with 
final are thread safe.

But I may be missing something.  I am more curious to see how we come to 
consensus on something like this, because the worst outcome from all this will 
be to have some folks actively adding final and some actively removing it, 
which will add noise to PRs and to the code.  And once we reach consensus, how 
do we enforce somethings like this? ./gradlew spA?

> On Jun 17, 2019, at 8:55 PM, Jacob Barrett  wrote:
> 
> I too am in camp final too. You could say `final boolean useFinal = true`. 
> For all the same reasons Bill stated below.
> 
>> On Jun 17, 2019, at 5:33 PM, Bill Burcham  wrote:
>> 
>> The final keyword is not redundant—quite the opposite—it's extremely 
>> valuable.
>> 
>> Local variables are not, in general, final, unless you declare them as such. 
>> That being the case, it is not redundant to declare local variables "final".
>> 
>> What the compiler will do for you, is _if_ it can ensure that a local 
>> variable (or method parameter) is never modified (after initialization) then 
>> that variable is treated as "effectively final". Variables that are 
>> explicitly declared final, or are determined to be "effectively final" may 
>> be referenced in lambdas. That's a nice thing.
>> 
>> I would like to offer a counter-recommendation: final should be the default 
>> everywhere for fields, for method parameters (on classes, not on 
>> interfaces), and for local variables.
>> 
>> Many benefits would accrue to us, should we adopt this default:
>> 
>> 1. final fields must be initialized in a constructor and never mutated 
>> again. This makes reasoning about those fields easier.
>> 2. classes that have all their fields final are immutable and hence easier 
>> to reason about: they can be passed between threads, for instance, with no 
>> need to protect from races
>> 3. final method parameters can never be mutated, making them easier to 
>> reason about
>> 4. final local variables can never be mutated, making them easier to reason 
>> about
>> 
>> When final is the rule, non-final is the exception. Another way of saying 
>> that is that when final is the rule, mutability is the exception. That is as 
>> it should be. Mutability is the enemy.
>> 
>> I have turned on a couple IntelliJ settings that make this the default for 
>> me. I encourage you to do the same:
>> 
>> First there are these two "Code style issues" in the Java inspections:
>> 
>> "Field may be 'final'"
>> "Local variable or parameter can be final"
>> 
>> 
>> 
>> Then there is this setting will cause newly-defined variables created via 
>> the "Extract variable" refactoring:
>> 
>> If you select that check box (after selecting those inspections settings 
>> above), it'll declare the newly-introduced variable "final" and it'll 
>> remember the setting the next time you invoke "Extract variable" refactoring
>> 
>> 

Re: Unnecessary uses of final on local variables

[Jacob Barrett]

I too am in camp final too. You could say `final boolean useFinal = true`. For 
all the same reasons Bill stated below.

> On Jun 17, 2019, at 5:33 PM, Bill Burcham  wrote:
> 
> The final keyword is not redundant—quite the opposite—it's extremely valuable.
> 
> Local variables are not, in general, final, unless you declare them as such. 
> That being the case, it is not redundant to declare local variables "final".
> 
> What the compiler will do for you, is _if_ it can ensure that a local 
> variable (or method parameter) is never modified (after initialization) then 
> that variable is treated as "effectively final". Variables that are 
> explicitly declared final, or are determined to be "effectively final" may be 
> referenced in lambdas. That's a nice thing.
> 
> I would like to offer a counter-recommendation: final should be the default 
> everywhere for fields, for method parameters (on classes, not on interfaces), 
> and for local variables.
> 
> Many benefits would accrue to us, should we adopt this default:
> 
> 1. final fields must be initialized in a constructor and never mutated again. 
> This makes reasoning about those fields easier.
> 2. classes that have all their fields final are immutable and hence easier to 
> reason about: they can be passed between threads, for instance, with no need 
> to protect from races
> 3. final method parameters can never be mutated, making them easier to reason 
> about
> 4. final local variables can never be mutated, making them easier to reason 
> about
> 
> When final is the rule, non-final is the exception. Another way of saying 
> that is that when final is the rule, mutability is the exception. That is as 
> it should be. Mutability is the enemy.
> 
> I have turned on a couple IntelliJ settings that make this the default for 
> me. I encourage you to do the same:
> 
> First there are these two "Code style issues" in the Java inspections:
> 
> "Field may be 'final'"
> "Local variable or parameter can be final"
> 
> 
> 
> Then there is this setting will cause newly-defined variables created via the 
> "Extract variable" refactoring:
> 
> If you select that check box (after selecting those inspections settings 
> above), it'll declare the newly-introduced variable "final" and it'll 
> remember the setting the next time you invoke "Extract variable" refactoring
> 
> 

Re: Unnecessary uses of final on local variables

[Bill Burcham]

The final keyword is not redundant—quite the opposite—it's extremely
valuable.

Local variables are not, in general, final, unless you declare them as
such. That being the case, it is not redundant to declare local variables
"final".

What the compiler will do for you, is _if_ it can ensure that a local
variable (or method parameter) is never modified (after initialization)
then that variable is treated as "effectively final". Variables that are
explicitly declared final, or are determined to be "effectively final" may
be referenced in lambdas. That's a nice thing.

I would like to offer a counter-recommendation: *final should be the
default everywhere for fields, for method parameters (on classes, not on
interfaces), and for local variables*.

Many benefits would accrue to us, should we adopt this default:

1. final fields must be initialized in a constructor and never mutated
again. This makes reasoning about those fields easier.
2. classes that have all their fields final are immutable and hence easier
to reason about: they can be passed between threads, for instance, with no
need to protect from races
3. final method parameters can never be mutated, making them easier to
reason about
4. final local variables can never be mutated, making them easier to reason
about

When final is the rule, non-final is the exception. Another way of saying
that is that when final is the rule, mutability is the exception. That is
as it should be. *Mutability is the enemy*.

I have turned on a couple IntelliJ settings that make this the default for
me. I encourage you to do the same:

First there are these two "Code style issues" in the Java inspections:

"Field may be 'final'"
"Local variable or parameter can be final"

[image: image.png]

Then there is this setting will cause newly-defined variables created via
the "Extract variable" refactoring:

If you select that check box (after selecting those inspections settings
above), it'll declare the newly-introduced variable "final" and it'll
remember the setting the next time you invoke "Extract variable" refactoring

[image: image.png]

Re: Unnecessary uses of final on local variables

[Jacob Barrett]

> On Jun 13, 2019, at 1:31 PM, Kirk Lund  wrote:
> 
> According to Effective Java 3rd Edition, all local variables are implicitly
> made final by the JVM…

Can you please provide a link or at least the chapter and item number that this 
statement is made in. I have scanned through the book and search online and 
haven’t found a statement in this book regarding final local variables. 

Thanks,
Jake

Re: Unnecessary uses of final on local variables

[Dale Emery]

> On Jun 13, 2019, at 4:15 PM, Ryan McMahon  wrote:
> 
> I agree with this sentiment, and have generally only been using final on
> class fields and method parameters where I want to guarantee immutability
> as of late.  However, I was at one time adding final to local variables,
> and I know that I have checked in code with final locals.  Should we
> actively be removing finals when we see it on locals?
> 
> One case where I still have been using final for locals is when the
> variable is effectively constant and I want to show that intent.  For
> instance:
> final String resourceId =
> "someStaticResourceIdThatReallyShouldntBeReassignedEver";
> 
> Is this a valid use case or should we view this as unnecessary verbosity as
> well?

My preference (fairly strong) is not to mark locals and parameters as final, 
but I won’t go so far as to say it’s invalid to do so.

I would like to know more about the intent, so …

If such a local variable were not marked final, what bad thing do you think 
might happen?

A more positive version of the same question: If you’re able to show that the 
variable is effectively constant, what good things does that do for you?

—
Dale Emery
dem...@pivotal.io

Re: Unnecessary uses of final on local variables

[Dale Emery]

> On Jun 13, 2019, at 4:29 PM, Juan José Ramos  wrote:
> 
> +1 to removing *final* on local variables.
> However, regarding Ryan's example, and even if it adds some "noise" to the
> source code, I'm in favour of keeping the *final* keyword on local
> variables whenever the developer wants to explicitly show the intent of
> making that the variable effectively constant.

How will we know whether it’s an explicit intention, vs an old habit or 
something else?

—
Dale Emery
dem...@pivotal.io



> On Jun 13, 2019, at 4:29 PM, Juan José Ramos  wrote:
> 
> +1 to removing *final* on local variables.
> However, regarding Ryan's example, and even if it adds some "noise" to the
> source code, I'm in favour of keeping the *final* keyword on local
> variables whenever the developer wants to explicitly show the intent of
> making that the variable effectively constant.
> Cheers.
> 
> 
> On Fri, Jun 14, 2019 at 12:15 AM Ryan McMahon  wrote:
> 
>> I agree with this sentiment, and have generally only been using final on
>> class fields and method parameters where I want to guarantee immutability
>> as of late.  However, I was at one time adding final to local variables,
>> and I know that I have checked in code with final locals.  Should we
>> actively be removing finals when we see it on locals?
>> 
>> One case where I still have been using final for locals is when the
>> variable is effectively constant and I want to show that intent.  For
>> instance:
>> final String resourceId =
>> "someStaticResourceIdThatReallyShouldntBeReassignedEver";
>> 
>> Is this a valid use case or should we view this as unnecessary verbosity as
>> well?
>> 
>> Thanks,
>> Ryan
>> 
>> 
>> 
>> On Thu, Jun 13, 2019 at 1:31 PM Kirk Lund  wrote:
>> 
>>> According to Effective Java 3rd Edition, all local variables are
>> implicitly
>>> made final by the JVM (and thus receiving the same JVM optimizations as a
>>> final variable) without requiring use of the keyword as long as you only
>>> set the value once. So this becomes an unnecessary use of the keyword
>>> final which
>>> really just adds noise to the code (one more word on many lines) much
>> like
>>> unnecessary uses of this. on references to class fields. The only context
>>> where it's still valuable to use final is on class fields and constants
>>> where it provides concurrency guarantees.
>>> 
>>> It may be useful to temporarily mark a local variable as final while
>>> performing a refactoring. See Martin Fowler's book for various
>> refactorings
>>> in which he does this.
>>> 
>>> There really is no value in retaining the keyword on a local variable any
>>> longer, so I think we should avoid using it in the same way we avoid
>>> unnecessary uses of this. on references to class fields. It's all just
>> more
>>> noise in the code.
>>> 
>> 
> 
> 
> -- 
> Juan José Ramos Cassella
> Senior Technical Support Engineer
> Email: jra...@pivotal.io
> Office#: +353 21 4238611
> Mobile#: +353 87 2074066
> After Hours Contact#: +1 877 477 2269
> Office Hours: Mon - Thu 08:30 - 17:00 GMT. Fri 08:30 - 16:00 GMT
> How to upload artifacts:
> https://support.pivotal.io/hc/en-us/articles/204369073
> How to escalate a ticket:
> https://support.pivotal.io/hc/en-us/articles/203809556
> 
> [image: support]  [image: twitter]
>  [image: linkedin]
>  [image: facebook]
>  [image: google plus]
>  [image: youtube]
> 

Re: Unnecessary uses of final on local variables

[Juan José Ramos]

+1 to removing *final* on local variables.
However, regarding Ryan's example, and even if it adds some "noise" to the
source code, I'm in favour of keeping the *final* keyword on local
variables whenever the developer wants to explicitly show the intent of
making that the variable effectively constant.
Cheers.


On Fri, Jun 14, 2019 at 12:15 AM Ryan McMahon  wrote:

> I agree with this sentiment, and have generally only been using final on
> class fields and method parameters where I want to guarantee immutability
> as of late.  However, I was at one time adding final to local variables,
> and I know that I have checked in code with final locals.  Should we
> actively be removing finals when we see it on locals?
>
> One case where I still have been using final for locals is when the
> variable is effectively constant and I want to show that intent.  For
> instance:
> final String resourceId =
> "someStaticResourceIdThatReallyShouldntBeReassignedEver";
>
> Is this a valid use case or should we view this as unnecessary verbosity as
> well?
>
> Thanks,
> Ryan
>
>
>
> On Thu, Jun 13, 2019 at 1:31 PM Kirk Lund  wrote:
>
> > According to Effective Java 3rd Edition, all local variables are
> implicitly
> > made final by the JVM (and thus receiving the same JVM optimizations as a
> > final variable) without requiring use of the keyword as long as you only
> > set the value once. So this becomes an unnecessary use of the keyword
> > final which
> > really just adds noise to the code (one more word on many lines) much
> like
> > unnecessary uses of this. on references to class fields. The only context
> > where it's still valuable to use final is on class fields and constants
> > where it provides concurrency guarantees.
> >
> > It may be useful to temporarily mark a local variable as final while
> > performing a refactoring. See Martin Fowler's book for various
> refactorings
> > in which he does this.
> >
> > There really is no value in retaining the keyword on a local variable any
> > longer, so I think we should avoid using it in the same way we avoid
> > unnecessary uses of this. on references to class fields. It's all just
> more
> > noise in the code.
> >
>


-- 
Juan José Ramos Cassella
Senior Technical Support Engineer
Email: jra...@pivotal.io
Office#: +353 21 4238611
Mobile#: +353 87 2074066
After Hours Contact#: +1 877 477 2269
Office Hours: Mon - Thu 08:30 - 17:00 GMT. Fri 08:30 - 16:00 GMT
How to upload artifacts:
https://support.pivotal.io/hc/en-us/articles/204369073
How to escalate a ticket:
https://support.pivotal.io/hc/en-us/articles/203809556

[image: support]  [image: twitter]
 [image: linkedin]
 [image: facebook]
 [image: google plus]
 [image: youtube]

Re: Unnecessary uses of final on local variables

[Ryan McMahon]

I agree with this sentiment, and have generally only been using final on
class fields and method parameters where I want to guarantee immutability
as of late.  However, I was at one time adding final to local variables,
and I know that I have checked in code with final locals.  Should we
actively be removing finals when we see it on locals?

One case where I still have been using final for locals is when the
variable is effectively constant and I want to show that intent.  For
instance:
final String resourceId =
"someStaticResourceIdThatReallyShouldntBeReassignedEver";

Is this a valid use case or should we view this as unnecessary verbosity as
well?

Thanks,
Ryan



On Thu, Jun 13, 2019 at 1:31 PM Kirk Lund  wrote:

> According to Effective Java 3rd Edition, all local variables are implicitly
> made final by the JVM (and thus receiving the same JVM optimizations as a
> final variable) without requiring use of the keyword as long as you only
> set the value once. So this becomes an unnecessary use of the keyword
> final which
> really just adds noise to the code (one more word on many lines) much like
> unnecessary uses of this. on references to class fields. The only context
> where it's still valuable to use final is on class fields and constants
> where it provides concurrency guarantees.
>
> It may be useful to temporarily mark a local variable as final while
> performing a refactoring. See Martin Fowler's book for various refactorings
> in which he does this.
>
> There really is no value in retaining the keyword on a local variable any
> longer, so I think we should avoid using it in the same way we avoid
> unnecessary uses of this. on references to class fields. It's all just more
> noise in the code.
>