If a method is longer than a handful of lines and I go in to refactor it I am going to start by making every variable I find final. Then I am going to figure out how to keep them final. By doing so you naturally produce smaller functional methods that are usually independently unit testable. Smaller methods can get jitted. Smaller methods can take less time to reach a safe point (see time to safe point issues in Java).
For this reason I strongly prefer on final everywhere and if you think you need a variable to not be final you should use that as an indicator to refractor your code. So, +1 for me for final everywhere. Also, please stop declaring variables miles away from their use. > On Apr 14, 2021, at 12:55 PM, Kirk Lund <kl...@apache.org> wrote: > > Our coding standard and our Design Decisions does NOT require using final > on parameters and local variables. > > Please do NOT request that I add or keep final on parameters or local > variables unless the community votes and decides that every parameter and > local variable should require the final keyword. I coded this way in the > past and I found that it resulted in noisy code with no benefit. We can > argue about using this keyword all you want but the fact is I'm against it, > and I will not embrace it unless this community decides that we need to use > it. > > Using final on instance or class fields does have a concurrency benefit and > I support that only. > > If you want to add final to every single parameter and local var in the > Geode codebase, then now is your chance to vote on it. Please vote. > > Thanks, > Kirk
