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 <bburc...@pivotal.io> 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<String> 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 >
