
All variables in Java must be final - mshafrir
http://codemonkeyism.com/all-variables-in-java-must-be-final/
======
alrex021
... 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.

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

~~~
viraptor
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?

~~~
Confusion

      Maybe you should just use another language [..]
    

Believe me, I'm trying :)

------
mpobrien
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

~~~
nradov
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....](http://java.sun.com/javase/6/docs/api/java/util/Collections.html)

~~~
lemming
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.

------
jefffoster
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?

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

------
lemming
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).

------
Tichy
Want to succeed? Try failing...

SCNR...

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

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

~~~
Tichy
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).

------
jgrant27
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_baker
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%.

------
twir
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
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.

~~~
twir
Wow, never knew one could do that.

~~~
nradov
You can't do that. It would require a language change, to make try/catch
blocks expressions.

~~~
eldenbishop
You can sort of do this in Groovy.

    
    
      def val = {try { 1 } catch(ex) { 2 }}.call()
      assert(1 == val)

------
city41
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)

------
Confusion
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
What is wrong with loops?

~~~
Confusion
:). 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.

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

~~~
crux_
Yes, please!

Signed, foldl

