>>> a lot of anonymous classes are using just that by boxing those vars in final arrays
final variables (primitive and references) will be accessible in the function literal, the proposal only states that 'capture of non-final variables' will not be supported.
What that refers to is the trick of transforming "int a;" to "final int[] a = {0}" and then referring to a[0] everywhere. This adds about 20 bytes of overhead on Sun's 32-bit JVM and memory pressure for almost no benefit whatsoever.
yes, but that syntax is unnecessary as the proposal allows for final variables (primitives and reference types) to be available in the function literal syntax
Comments
>>> a lot of anonymous classes are using just that by boxing those vars in final arrays
final variables (primitive and references) will be accessible in the function literal, the proposal only states that 'capture of non-final variables' will not be supported.
What that refers to is the trick of transforming "int a;" to "final int[] a = {0}" and then referring to a[0] everywhere. This adds about 20 bytes of overhead on Sun's 32-bit JVM and memory pressure for almost no benefit whatsoever.
yes, but that syntax is unnecessary as the proposal allows for final variables (primitives and reference types) to be available in the function literal syntax
final int a = 0;
is all you need in the example you provide.
Not if you want to change the value of a.
And that's not the only case.
For instance you may want "a" to be mutable, but you also want to use its value when the closure gets executed.
I don't think I've ever used a framework in Java that relies on event-handlers / callbacks where I didn't had to box local variables.