The second part of the puzzle has to do with semantic of the Java language. Imagine that the compiler drops the ‘final’ requirement, requiring only that the variable is initialized prior to the call of the constructor. The data can make into the inner class just OK, but since we’ve made a copy, the new variable gets a lifecycle of its own. This means that any assignments to it will not be reflected in the value of the local variable, thus exposing the fact that the compiler has performed a copy. In other words, the programmers will see two variables when in fact they have declared only one; a requirement of declaring the variable final gracefully deals with this inconsistency.

Well it’s not allowed in Java, but it is allowed by the bytecode verifier – which has other ways of ensuring that the superclass constructor is always called.

Decompilation reveals why:

JDK 1.4.2:

class Outer$1 {
Outer$1(final s) { var$s = s }
}

JDK 1.5:
class Outer$1{
Outer$1(final s) { var$s = s;
super(); }
}

So JDK 1.4 calls the super-constructor before setting the hidden var$s, and JDK 1.5 first sets the var$s and then calls the super-constructor (I thought this is not allowed in Java, because super() must be the first instruction in the constructor method).

u will get the source code