Thursday, April 7, 2011

Final is my favorite Java keyword

Final is my favorite keyword and modifier in Java.  For fields, love it even more than private.  Think about it, you don't even need private on your field if it's final.  Not with a truly non-mutable data type at least, so collections and things of that nature excluded of course.

In fact I wish final was the default modifier for all my fields, variables, and parameters.  You should have to announce your intention to overwrite an already initialized object reference.  After years, I find it is a rarity.

There is nothing worse that digging through a large 500 line function and not being able to see what is changed and where.  Even more frustrating when you go to extract a method from said too-large codeblock and cannot do so easily because of the sprawled out variable declarations and initializations and the occasional "I like this variable name so I'll reuse the reference" laziness.

The trouble is it looks so terrible when used properly, which should be almost everywhere!  It looks pretty satisfying on fields, but over all parameters and variables it gets to be a little much.  It can actually make it harder to find the non-final object references.  And if you find one, was it intentional or just overlooked? Change it and find out I guess.

That is why one of my biggest wishes for the Java language is that final be the default and there to be a mutable or similar keyword for the handful of times you need it.  It would be an excellent aid to readers of your code, "watch out this thing is going to change." Compilers could even check to see if you have flagged something mutable and aren't actually mutating it.  That should be a compile error for variables and parameters, perhaps not for fields though.

Obviously we can't exactly do that ... not so directly.

We have some advantages now we didn't have when Java was created.  Annotations.  When Java was created there had to be long and deliberate thinking as to what the defaults should be.  Everyone would have to live with them and they'd last forever.  These days, however, a simple annotation or two on a Java source file could serve as a clean way to change such defaults in an obvious and documented way that can make the code in question far easier to read.  It would be syntactic sugar of course and that annotation and the defaults it specifies would compile away just as imports do.

A small bit of sugar with big payoff in ease and readability.


Ortwin said...

Cool, and if all your variables are final, you don't even need to run the code! You can optimize it away completely in the compiler and reduce it to its (constant) result.

tug said...

I agree completely.

Adam Rabung said...

Two little nits - a private final field is still better than a final field, because it encapsulates/hides the field - minimizes api surface area. Also, "mutable" keyword would not be good because final Objects _are_ mutable, they're just not reassignable.

David Blevins said...

@Adam Good point. Perhaps 'assignable' is the better keyword. In terms of a get method for a final reference to a non-mutable object, was more making a statement of technical necessity rather than one of best practices. Likely high on the list of things we do that hotspot will remove because it isn't technically necessary.

Viktor Klang said...

Ortwin: Well, I kinda need branching, so your fold-into-constant-result will have to wait.

Brian Goetz said...

This is exactly the sort of thing you can do for yourself with JSR-308 and the Checkers framework. Write your own @FinalByDefault class annotation and @Mutable field annotation, write a checker to verify your rules, and you're done.

You can start on this today using the JSR-308 prototype now!

timothymattie said...

more or less into collaboration. Wow! Right now probably weigh over head but what do you guess(ebaan) is direction of a WLAn Coova Hotspot is it worth looking up related. API's, FBML's,FBTS'S,and FQL's.Coova has good Open source, and Java credentials! Appreciated!!