int a = 25;
someMethod( a );
System.out.println( a );
private void someMethod( int arg ) { .. }
will always produce 25 as output, irregardless of what happens in someMethod();
List a = new ArrayList();
someMethod( a );
System.out.println( a );
private void someMethod( final List arg ) { .. }
here, final does NOT prevent the modification of the ArrayList.
final List a = new ArrayList();
someMethod( a );
System.out.println( a );
private void someMethod( final List arg ) { .. }
And I can STILL modify the arraylist as much as I want.
Even
int[] a = new int[5];
a[0] = 1;
someMethod( a );
System.out.println( a[0] );
private void someMethod( final int[] abc )
{
abc[0] = 0;
}
will be allowed by the compiler as well as the runtime.
Any combination I can think of, doesn't change the fact that "final"
does NOT in any way enforce immutability.
The more I think about it, the more I am convinced that it is even bad
to use it for local variables and method arguments, as it doesn't
assist in cross-developer communications.
And if you can't track a couple of variables in a 10 line method, then
I think you need to pick another profession. ;o)
For methods and classes --> I am all for final as much as possible.
But that is to enforce strict obedience to inheritence, which
otherwise easily creates incompatibility problems in the future.
For members, I am Ok with final, as it is much harder to get an
overview of all usages within a class, than a small method.
Cheers
Niclas
_______________________________________________
qi4j-dev mailing list
[email protected]
http://lists.ops4j.org/mailman/listinfo/qi4j-dev
