Effectively final effective?

Alex Blewitt alex.blewitt at gmail.com
Fri Feb 26 11:46:23 PST 2010


On Fri, Feb 26, 2010 at 1:09 PM, Reinier Zwitserloot
<reinier at zwitserloot.com> wrote:
> NB: Jesse, regardless of the pros and cons of making a backwards
> incompatible java 2.0 release, Java 7 most assuredly is not going to be such
> a release.

One problem with the change of semantics of 'effective final', if it
applies to inner classes, is that it introduces the possibility of
Java programs compiled with Java 1.7 to be incompatible with one
compiled for 1.6. Clearly, one cannot use pre-1.7 features (closures,
coin features) when compiling on a 1.6 compiler (or, using a -source
1.6 flag), but it will mean that developers will be able to write:

public class Outer {
  public void method() {
    boolean nonFinal = true;
    new Inner {
      boolean foo;
      void other() {
        foo = nonFinal;
      }
    }
  }
}

On a 1.7 compiler, this will compile without error. On a 1.6 compiler,
the lack of 'final' on the 'nonFinal' variable will cause a compile
time error. So it's still possible to be backwardly incompatible, even
if not using any of the 'new' features like lambdas, method
references, coin syntax improvements etc.

Alex


More information about the lambda-dev mailing list