To anyone/everyone else reading this
thread.
I am one of the strongest proponents of annotating logically
final instance members, static members and local variables as explicitly
final.
It is a nice warning to anyone mucking about with my code that "Kindly don't mess with that once it has been set, or you are very liable to break the functioning of this class/object/method."
Leaving it out in those cases seems like an accident that can hardly wait to happen, and just to save six characters--I generally put it in.
I picked up from Very Wise People that annotating one's constructor and method parameters as such, on the other hand, is generally a rather silly waste of space.
In C++, the Wise Wizards seem even more against it there. It is one of countless things that the language definition lets you do that
you should just always avoid.
It buys you nothing and costs you precious horizontal space...
This code feels like it was written by someone who knows Java much better than I do, yet...
There are many painfully long lines that make you ride the scroll bar pretty heavily to read them, especially painful when trying to match code to error messages, but really, always.
There are many methods that decide to decorate their
parameters with
final.
Some of the Very Long Lines are method definitions that decide to decorate their
parameters with
final.
I believe these were the lines in my crude and only partially-successful attempt at avoiding by re-formatting Very Long Lines in the OP's code that followed that practice:
32, 38, 45, 131, 149, 154, 161, 168, 174, 236, 241
Now, I also always thought that "effectively final local variables" were an overblown feature, because I am a big fan of marking final things final anyway.
If they just happened to be final at that moment in code evolution, rather than logically so, and someone comes along and wants to capture them in a lambda/closure or anonymous class instance, now I got pasted into a corner. I didn't even mean for those to be
final, but now they are, etc. etc.
But maybe the use case was for exactly what I am seeing here?
There were lots of times that
lambdas or code in anonymous local classes maybe would want to capture the values of method parameters, and until "effectively final" those all had to be marked final in the parameter list to the method, which was cluttering it up and making it hard to read? So now, with "effectively final" we can actually read the method definitions without seeing an extra
final five times?
Is this likely code that was written pre-Java 8, and therefore wanted to allow code in possible anonymous class instantiations to read the parameters?
Was it just written by people who always eat pizza with a knife and fork?
I had no trouble reading the last 50 or 60 pieces of Java code I have looked at. This one was hard.
There may be some places where
var could have helped as well, if it didn't need to target Java versions prior to 10, but the question here is about all the method parameters explicitly marked
final, especially in lines that were already uncomfortably long.