Effectively final effective?

[Reinier Zwitserloot]

I don't understand. There is no source incompatibility.

That is, it is perfectly allright for a new language feature to make
previously illegal code, legal. For example, this:

for (String x : foo) {}

was illegal in java 1.4. It was legal in 1.5.

--Reinier Zwitserloot



On Fri, Feb 26, 2010 at 8:46 PM, Alex Blewitt <alex.blewitt at gmail.com>wrote:

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