Inizializzazione ordine dei campi finali

Question

Consideriamo queste due classi:

public abstract class Bar { 
    protected Bar() { 
     System.out.println(getValue()); 
    } 

    protected abstract int getValue(); 
} 

public class Foo extends Bar { 
    private final int i = 20; 

    public Foo() { 
    } 

    @Override 
    protected int getValue() { 
     return i; 
    } 

    public static void main(String[] args) { 
     new Foo(); 
    } 
} 

Se eseguo Foo, l'uscita è 20.

Se faccio il campo non finale, o se inizializzare nel Foo constructor, l'output è 0.

La mia domanda è: qual è l'ordine di inizializzazione in caso di campi finali e dove si trova questo comportamento descritto nella JLS?

Mi aspettavo di trovare qualche regola eccezionale sui campi finali here, ma a meno che non mi manchi qualcosa, non c'è.

Nota che so che non dovrei mai chiamare un metodo overridable da un costruttore. Non è questo il punto della domanda.

Answer 1

La variabile membro final int i è una variabile costante: 4.12.4. final Variables

Una variabile di tipo primitivo o tipo String, che è final e inizializzato con una fase di compilazione espressione costante (§15.28), è chiamato variabile costante.

Ciò ha conseguenze per l'ordine in cui le cose sono inizializzate, come descritto in 12.4.2. Detailed Initialization Procedure.

Answer 2

Camminare attraverso il modo in cui questo appare in un modo "byte-code-ish".

Si dovrebbe già essere consapevoli del fatto che la prima istruzione effettiva in un costruttore deve essere una chiamata a super (sia con argomenti o senza).

Questa istruzione super restituisce quando il costruttore genitore è terminato e il super "oggetto" è completamente costruito. Così, quando si costruisce Foo si verifica quanto segue (in ordine):

// constant fields are initialized by this point 
Object.construction // constructor call of Object, done by Bar 
Bar.construction // aka: Foo.super() 
callinterface getValue() // from Bar constructor 
// this call is delegated to Foo, since that's the actual type responsible 
// and i is returned to be printed 
Foo.construction 

se si dovesse inizializzare nel costruttore, che sarebbe successo "ora", dopo getValue() erano già stati chiamati.

Answer 3

Ecco una versione ancora più subdola, solo per divertimento.

public abstract class Bar { 
    protected Bar() { 
     System.out.println(getValue()); 
    } 

    protected abstract Object getValue(); 
} 

public class Foo extends Bar { 
    private final String i = "Hello"; 

    public Foo() { 
    } 

    @Override 
    protected Object getValue() { 
     return i; 
    } 

    public static void main(String[] args) { 
     new Foo(); 
    } 
} 

Risultato: stampa Hello.

Ora cambiare questa linea:

private final String i = "Hello"; 

a:

private final Object i = "Hello"; 

Risultato: Stampe null.

Questo perché String (e tipi primitivi) sono gestiti appositamente come descritto in JLS 4.12.4 che ho citato nella mia altra risposta.