Sorry for responding so late: I don't think final is about immutability. You stated some of the more obvious examples of non-immutable references. Actually I think in the Java VM there is no real immutability, you can change almost everything: final variables, add new Enums instances, remove security access and so forth. (See Heinz Kabutz Java Specialist Newsletter for some of these surprising observations, Java Puzzlers helps there as well). e.g. http://www.javaspecialists.eu/archive/Issue096.html
So what is final about: Imho its about communicating intent. I intent that this variable is only assigned once, so I have a single place to look at/for when I'm interested in the reference-value of the variable. Mostly this also means that the value assigned there is not changed in the scope of the variable. If I don't use final at all, I don't communicate anything about the intent of "single sourcing" the reference value. I have to scan the whole block for possible (re-)assignments and be careful not to overlook/misinterpret some especially difficult logical or structural construct. When using final the compiler cares for this (evaluating the constructs to assure it is assigned only once). If I use final and on some variables/parameters don't I communicate for these that I intent to reuse them. So it is expected that there are several assignment locations for them (and this is then not surprising). So using final lessens the mental burden of keeping in mind which variables are only assigned once (refer to a single instance of an type). And which are reused. I'd rather not reuse variables and parameters. Mostly I revert to a more functional style and create small method calculating the value and returning it to the main scope (idempotent query methods) (refactorings: extract method, convert temp to query-method, convert expression to named method). You're right when you say that if your methods are small then final is not neccessary. But when looking at the code in most professional projects and even the (existing) qi4j runtime long methods of more that 10 lines are ubiquitous. So making all possible local variables and parameters final is a first step during refactoring that helps scoping the method and extracting methods which are either commands or queries. These can then much easier be tested as well as their scope is limited and they do just one thing. Michael Niclas Hedhman schrieb: > Obviously the milage varies a lot in this. I can't recall chasing any > bugs originating from missing final. I have chased a bug where arrays > has been modified or reused, but final doesn't prevent that. I am > still -1 to introduce this all over the place. Show me a real bug > which could be prevented by a final method argument or final local > variable. -- Niclas > > On 5/25/08, Michael Hunger <[EMAIL PROTECTED]> wrote: >> Thank David I couldn't agree more. It denotates and communicates which >> parameter/local variable _references_ are immutable and should not be >> reassigned/reused which is a common and hard to find problem (e.g. typo) >> if you reuse params/local variables. I spend many hours looking for this >> kind of errors in different codebases and have to say that I rather >> spend these hours writing productive code :). >> >> It also stresses the query character of many functions (side effect >> free). If you combine this with real immutable parameters and variables >> you have a consistent immutability. With some VMs you help the garbage >> collector and hotspot when using final, but imho the current Sun JVMs >> don't need that anymore if you enable escape analysis. >> >> Having the compiler complaining this (or rather the IDE) is quite >> convenient. >> >> I also use final on foreach iterator values. >> >> I'd rather have this as the default in the language and explicitly mark >> non final stuff but thats to late by now :). >> >> Michael >> >> David Leangen schrieb: >>>> I must say that I have never understood the "final" on method >>>> arguments. It doesn't bring any value. If the method argument is a >>>> native type, I can change it as much as I want as it doesn't modify >>>> the caller's value. If the argument is a mutable object, "final" >>>> doesn't stop me from modifying the object, only the reference which in >>>> turn doesn't affect the caller. Similar for local variables. And IMHO, >>>> "final" adds a lot of clutter everywhere. I like using "final" where >>>> it makes a difference, not out of principle. -- Cheers, Niclas. >>> The point is that unless you can _guarantee_ that parameters are >>> immutable, >>> then a lot of damage and bad side effects can happen during a method call. >>> >>> The simplest way of adding an extra layer of protection is to simply add >>> "final" to the method param. That way you know for sure at compile time >>> (i.e. more brainless stuff to take a load off all the already existing >>> complexity in the system) that you're not causing any side effects. >>> >>> >>> YMMV, but I've found that once you get used to "final", you don't even >>> notice it anymore. In fact quite the opposite: you notice more when it's >>> _not_ there (which I guess is the whole point of having it in the first >>> place). >>> >>> >>> Cheers, >>> Dave >>> >>> >>> >>> _______________________________________________ >>> qi4j-dev mailing list >>> [email protected] >>> http://lists.ops4j.org/mailman/listinfo/qi4j-dev >> >> -- >> Michael Hunger >> Independent Consultant >> >> Web: http://www.jexp.de >> Email: [EMAIL PROTECTED] >> >> Enthusiastic Evangelist for Better Software Development >> We support Software Engineering Radio (www.se-radio.net) >> >> _______________________________________________ >> qi4j-dev mailing list >> [email protected] >> http://lists.ops4j.org/mailman/listinfo/qi4j-dev >> > _______________________________________________ qi4j-dev mailing list [email protected] http://lists.ops4j.org/mailman/listinfo/qi4j-dev
