All variables in Java must be final

http://codemonkeyism.com/all-variables-in-java-must-be-final/

by mshafrir • 16 years ago

15 34 16 years ago

Confusion5• 16 years ago

As argued in, for instance, Hardcore Java[1], 'final' should definitely have been the default for variables in Java. My Eclipse 'on save' actions include making every possible local variable, parameter and field final. If I'm reading the code and one of them is not final, I know it requires some extra attention.

[1] http://oreilly.com/catalog/9780596005689

Retric• 16 years ago

What is wrong with loops?

Confusion5• 16 years ago

:). I didn't mean it like that. I meant that when I'm reading code, I know to pay extra attention when something is not final. There will always be non-final variables around, for instance 'previousItem' to track the previous item through a loop. Added some words to the parent to clarify.

bokchoi• 16 years ago

Perhaps we should go even farther -- 'final' should be default on methods and classes as well. Derivation should only be allowed where explicitly granted by a programmer.

alrex0212• 16 years ago

... and all methods must be static with no side effects. Additionally, use functors to simulate crippled closures and you have a broken FP paradigm embedded in you cup of Java.

Confusion5• 16 years ago

... and ridicule the article/Java, instead of acknowledging that it rightly argues that the average Java program benefits from less occasions for mutability.

viraptor• 16 years ago

It might rightly argue that. But java suffers from being too verbose and not flexible enough. Now someone proposes to add another keyword to 99% of declarations to make java act in a similar to what some other languages do by default. Maybe you should just use another language if state (i.e. the standard way of programming in java) bothers you that much?

alrex0212• 16 years ago

I acknowledge the author's arguments and recommendations. However, I do feel I have the right to exercise my freedom of speech, even if its tongue-in-cheek. That said, my view is that Java, the language, has some deeply rooted flaws.

proemeth• 16 years ago

What about loop variables? Want to re-allocate them at each step?

crux_• 16 years ago

Yes, please!

Signed, foldl

nradov4• 16 years ago

I make variables inside loops final. The compiler should automatically handle that and avoid unnecessary re-allocation.

j_baker2• 16 years ago

Chances are a few (or probably even a lot of) temporary references aren't going to be that big a deal.

Tichy2• 16 years ago

Want to succeed? Try failing...

SCNR...

Seriously, though, I've come to think of Java as "fear driven development".

Confusion5• 16 years ago

Someone advocates less mutability and instead of applauding that, you start scoffing Java. Is Lisp a fearful language?

Tichy2• 16 years ago

It's not really the mutability I don't like about Java anymore. I don't have enough experience with immutability, except for doing some Project Euler problems in Erlang. There I kind of hit a wall trying to compute primes efficiently (the seave was not possible with immutable lists).

mpobrien• 16 years ago

Except newbie programmers should keep in mind that final is not simply synonymous with immutability.

  final ArrayList x = new ArrayList(); // x is final, so it can't be reassigned
  x.add( "foo" ); // but we can still modify its contents

city412• 16 years ago

It is synonymous with immutability though, in the strictest sense. In this case x and the ArrayList are two different things, one is final, the other is not. Yeah it's an anal distinction, but still a valid one.

nradov4• 16 years ago

The java.util.Collections class has several methods for making collection objects immutable. I use those whenever possible. Of course that only prevents changes to the collection, it doesn't prevent changes to individual collection elements.

http://java.sun.com/javase/6/docs/api/java/util/Collections....

lemming2• 16 years ago

It's worth noting that this doesn't actually provide an immutable collection, it provides an immutable view of an existing one. If some other code has a reference to the underlying collection it can still be mutated. However this works well for the common case where you have a method which creates a local collection and returns the immutable view - in that case the collection is effectively immutable.

twir3• 16 years ago

This is a great philosophy, but I'd hesitate to say "all" variables; sometimes it just doesn't work out.

ex, in class definition:

  final int foo;

In constructor:

  try {
    foo = 1;
  } catch ( Exception e ) {
    foo = 2;
  }

lsb• 16 years ago

If your try{} catch{} blocks were expressions, not statements, you could write

  foo = try { 1 } catch(Exception e) { 2 }

much like the foo = bool ? 1 : 2 ternary if statement, versus the if() {} else {} clauses.

twir3• 16 years ago

Wow, never knew one could do that.

nradov4• 16 years ago

In cases like that I usually exact the try/catch block into a separate private method which returns an int. Then the constructor can just call that method and use the return value to set foo.

city412• 16 years ago

The final keyword in Java is great. It's probably the only design decision I think Java really got right compared to C# (sealed, readonly, const? bleh)

jefffoster• 16 years ago

It's a poor substitute for C++'s const though - at least that lets you reason about the state of an object. Java's final keyword just stops you reassigning a reference - how many times do you inadvertently do that?

brown9-2• 16 years ago

More than you might think

pyre• 16 years ago

The point here is that if final functioned like const, you wouldn't be able to advocate 'using it everywhere' like he is.

jgrant27• 16 years ago

The very first code snippet is NOT valid Java and yet the author claims decades of programming experience (about page). He also seems to have very recently discovered the side-effects of imperative programming.

j_baker2• 16 years ago

I'll agree that all variables should be final. However, you're applying a functional constraint (that most functional languages provide workarounds for) to an imperative language. I just don't feel it's reasonable to expect a java programmer to obey rules that languages like ocaml don't even enforce 100%.

lemming2• 16 years ago

This article fails to mention the main benefit of final - it gives you much stricter guarantees for concurrency under the Java Memory Model. If you create an immutable object and the fields are final, you can immediately pass the object to another thread without synchronisation - this is not safe if the fields are not final but are otherwise immutable.

For this reason we enforce that all object member fields must be final if possible, but we don't enforce it for local variables or method parameters. There are benefits to be had by doing that as well but IMO the benefit outweighs the return (and our IDE, IntelliJ, warns us if we reuse a local variable or method parameter).

All variables in Java must be final

Related Stories