[PJUG Javamail] primitive method argument as primitive and final

[Seth Wright]

Oh oh oh, my 2 cents (I wish email was a more expressive medium because I'm
pretty sure that doesn't come across right - ah well.:

There are a couple of reasons I could see for doing declaring a primitive
type as final.  1) as mentioned before is defensive programming - and
frankly, I think it's just good style because code should be as expressive
as possible.  I say this because the project I work on has a decent sized
code base and as the person finally responsible for it, I want to be able to
just skip to a piece of code and require as little context in reading it as
possible.  Also, I think a lot of developers have this notion that when
coding, if they do any of it defensively, it's to protect themselves from
some moron doing the wrong thing when the right thing is obvious.  In my
case, I do it because I recognize that the most likely person to screw up my
code is me, so I'll put final somewhere just to keep myself from doing
something stupid.

2) you have to declare a local variable as final if you want to use an
anonymous class.  This restriction is due to the way Java implements
anonymous classes as closures.  (Reference:
http://renaud.waldura.com/doc/java/final-keyword.shtml#vars)

There is also another valid reason to do this in regards to the Java memory
model and running on a multiprocessor machine.  It allows the JVM, if
running on multiple processors, to do some memory management tricks in
regard to memory synchronization/etc.  If it knows the value will not
change, even locally, then it doesn't have to synchronize access to this
memory across processors - also it allows the Hotspot compiler to,
potentially, shift memory access instructions around so as to optimize
things.  Or at least that's how I understand things. (Reference:
http://www.cs.umd.edu/users/pugh/java/memoryModel/)

Granted, I see the argument that really only objects are going to be a
problem with this, but keep in mind that if you declare a parameter that is
a class as final, you can modify the object that it is already pointing to,
you just can't change which object it is pointing to.  E.g. this is totally
legal:
    private static void testerTwo(final Tester tester) {
        tester.testerValue = 123;
    }


On 2/19/07, Chris Kessel/Lou Doherty <chriskessel at verizon.net> wrote:
>
>
> This is all sort of a side note, but...
>
> ---
> You are correct in that modern compilers do not need the final keyword,
> but
> to me, the main argument for using the final keyword is to clarify to
> yourself what the code should be doing.
> ---
>
> I've heard this several times and I get the theory behind the statement,
> but
> I don't really think it actually makes any difference. Best practice means
> you don't muck with input variables, so the "final" keyword on an input
> variable seems superfluous these days. In C/C++ not mucking with input
> variables matters because you might be screwing with a primitive someone
> else has a pointer to because they did a pass by reference. C/C++ provides
> "const" for that and consequently, I've seen a number of times where
> Java's
> "final" is used as a cheap javadoc-like way to mean "const", even though
> they aren't the same thing.
>
> When I see someone declare an input variable as "final" a few things run
> through my mind:
> 1) Did they mean const? If so, does the original coder understand Java
> references aren't C/C++ pointers?
> 2a) Does this mean their "default practice" is to modify input variables?
> Ewwww...
> 2b) Do they often write methods so incredibly long the "final" isn't
> obvious
> anyway? Also ewwww... :)
>
> Any decent developer already assumes "final" and adding the keyword is
> just
> clutter. And it can't protect against a poor engineer just going
> "duh...stupid final, I will remove it...". :)
>
> Chris
>
> _______________________________________________
> Web Site - http://www.pjug.org/
> Javamail mailing list
> Javamail at pjug.org
> http://www.pjug.org/mailman/listinfo/javamail
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://javac.com/pipermail/javamail/attachments/20070219/e0dd5a6a/attachment-0003.html>