compiler optimizes away a final field added to a serialized class

This is a strange one, am wondering if this is by design or a compiler bug. Am using Sun Java 6 on a PC, but also seen with Sun Java 5 on a linux box.

Suppose I have a file on disk containing a serialized class. I then add a final field to the class and declare and initialize the field in one statement:

public final int newField = 2;

If I read in an object that was serialized before this field was added, this new field is given a default value of 0, which is correct. However, the compiler replaces occurrences of the field by the constant "2". OTOH, if I instead initialize the new field inside of a constructor:

开发者_JAVA百科Data (int d) {
    this.oldField = d;
    this.newField = 2;
}

then the field does not get optimized away and everything works as expected.

More explicitly, here is my Main class:

import java.io.*;
public class Main {
    public static void main(String[] args) {
        try {       
            FileInputStream fis = new FileInputStream ("Data.txt");
            ObjectInputStream ois = new ObjectInputStream (fis);

            Data d = (Data)ois.readObject();
            ois.close();
            fis.close();

            d.print();
        }
        catch (Exception e) {
            e.printStackTrace();
        }
    }
}

and here is the Data class:

import java.io.*;
public class Data implements Serializable {
    private static final long serialVersionUID = 1;
    private int oldField;
    private final int newField = 2;

    Data(int d) {
        this.oldField= d;
    }

    public void print() {        {
        System.out.println(this.oldField + " " + this.newField);
    }
}

So my Data.txt file has a serialized instance of the original class with just "oldField = 1". So the expected output of running this is

1 0

but instead I get

1 2

whereas if I move the initialization into the constructor the output is correct.

Is this expected behaviour? My feeling is that the compiler should not be optimizing away fields in serialized classes, precisely for this reason. Perhaps that is asking too much. Thanks!

This is by design. If a variable is declared as final, has a primitive type and an initializer which is a constant expressions, then it is a "constant variable". This alters the semantics of initialization among other things. Specifically, the expression value is evaluated at compile time, and then embedded into the code.

Refer to JLS 4.12.4 for details.

When you put the initialization into the constructor, the variable is no longer a "constant variable" and normal initialization occurs.

By the way, I would have thought that a final variable having a different value than what the initializer said was a bad thing, not a good thing. To me, that would be highly unintuitive. At any rate, relying on this kind of behaviour does not strike me as good practice.

It's not clear why you think this is a problem. The compiler is doing exactly what it should do. The class definition says that the final field's value is 2, and that is exactly what you're getting.

The underlying reason is that when the final variable's value is declared in the initializer, the compiler knows its value immediately, so it is able to substitute the actual value as a literal wherever you use the variable. When you initialized it in constructor code, it couldn't see the value so easily so it doesn't do that optimization. It is still free to do so if it can.

In the language of the JLS #4.12.4, this is a 'constant variable', and JLS #13.1 says 'References to fields that are constant variables (§4.12.4) are resolved at compile time to the constant value that is denoted', which is exactly what is happening here.

My feeling is that the compiler should not be optimizing away fields in serialized classes

Why should the compiler have different rules for serialized classes?

The usage of final variable always provokes compiler optimization. Its doing what it supposed to do.