@jake, you are correct, I did miss the LOCAL variable out of the subject.
:face_palm:
Yes, adding "final" to LOCAL variables will be HUGELY beneficial in this
regard. Have we seen any performance improvement after having refactored this
method? Have you been able to measure any improvements?
--Udo
On 4/15/21, 1:19 PM, "Jacob Barrett" <jabarr...@vmware.com> wrote:
> On Apr 14, 2021, at 7:46 PM, Udo Kohlmeyer <u...@vmware.com> wrote:
> @Jake the idea of smaller methods is great and we should ALWAYS strive
for that. But that argument is completely irrelevant in this discussion. As
making method arguments final does not naturally guide a developer to creating
smaller methods. Nor does a smaller method mean it can/will be jitted. Too many
factors (to discuss here) are part of that decision, also it is not relevant in
this discussion. But more on that topic read THIS.
The original subject is in regards to parameters and local variables.
Irrelevant is certainly an opinion you are welcome to have but let me
challenge you. Goto DistributedCacheOperation._distribute().
First challenge, look at around line 333:
boolean reliableOp = isOperationReliable() &&
region.requiresReliabilityCheck();
Without scrolling do you see that variable used? Nope, because it is first
used on line 439, ~100 lines away. Does it mutate between there, well I can
search for all uses and find out or I could be nice to the next person and
intend for it to never mutate by adding final. Intent communicated!
Second challenge, mark all the local variables in the method as final. Now
make it compile without introducing more mutable variables. At the end of this
journey you will have about a dozen unit testable methods and a _distribute
method that goes from ~370 lines to ~90 with no mutable local variables.
I argue it is relevant as good guardrail for writing good code. While we
should ALWAYS strive for it we don’t. Every little nudge helps.
-Jake
