The language currently requires the use of final for parameters which
are used within an anonymous inner class. This use of final is only
relevant to the implementation of a method. It is never of interest to
clients of a method.

Mark Thornton

    I don't think so.  You'd then need a `nonfinal' keyword
to override the implicit finality, or else you'd need to
copy parameters to non-final local variables.

    You say you modify only one in ten thousand parameters.
For my part, I find I modify somewhat more than that, usually
when I want to "normalize" them somehow.  For example, I have
a Fraction class that represents rational numbers as a pair of
BigInteger values, and in the constructor I want to enforce a
few things:

    public Fraction(BigInteger num, BigInteger den) {
       // ensure that they're actually BigIntegers
       if (num.getClass() != BigInteger.class)
           num = new BigInteger(num.getBytes());
       if (den.getClass() != BigInteger.class)
           den = new BigInteger(den.getBytes());

       // ensure that the denominator is non-negative
       if (den.signum() < 0) {
           den = den.negate();
           num = num.negate();
       }

       // ensure relative primality
       if (den.signum() != 0) {
           BigInteger gcd = num.gcd(den);
           if (! gcd.equals(BigInteger.ONE)) {
               num = num.divide(gcd);
               den = den.divide(gcd);
           }
       }

       // now in "canonical form;" proceed with construction
       ...
    }

This pattern of "progressive regularization" seems natural to
me: I have three (in this case) conditions to enforce, so I test
each in turn and adjust things as necessary.  I *could* leave
the parameters alone and copy them to local variables, but what
benefit would that bring?

    I use it when the parameter's value will be referenced
by an inner class:

    void method(Thing thing) {
       gizmo.addChangeListener(new ChangeListener() {
           public void stateChanged(ChangeEvent evt) {
               thing.doSomething(evt);
           }
       });
    }

... will not compile as it stands.  Adding `final' to the
method parameter fixes things.

I don't use final on parameters.

It does not really provide anything and just clutters the code.

Arne

If we had the language design to do this over again, I think it would
make more sense to default to final and require a "mutable" or "var"
keyword.  Unfortunately it is too late now. You can't change that in
an upward compatible way.  Perhaps the designer's of Java's successor
(e.g. Fortress) might be able to correct that.

Though compilers can effectively put the final in itself, it is great
documentation ESPECIALLY when it is missing, to warn you to look for
redefinition.
--

Roedy Green Canadian Mind Products
The Java Glossary
http://mindprod.com