Correctly analyse array field mutation

[Grundlefleck]

Original author: Grundlefleck@gmail.com (November 15, 2011 22:34:46)

Currently the following class will be called mutable:

public final class ImmutableButHasUnmodifiedArrayAsField {
private final int[] unmodifiedArray;

public ImmutableButHasUnmodifiedArrayAsField() {
    this.unmodifiedArray = new int[] { 3, 14 };
}

public int getWhole() {
    return unmodifiedArray[0];
}

public int getFraction() {
    return unmodifiedArray[1];
}

}

However, this class is immutable (effectively immutable if the field is not marked final). It is ensuring exclusive access to the mutable components (including the elements of the array, which would not be true if replacing int[] with a mutable type, e.g. List<>[]). An update to the analysis should allow such a class under the following rules:

1. the array is not passed into constructor as a parameter
2. the array does not escape (but consider if the "best guess" analysis of the escaped this reference checker will be good enough, if not, probably should abort).
3. the type of array is immutable
4. the references in the array are never changed, e.g. myArray[1] = 42

(Depending on the success of this attempt, the same rules could extend to any mutable type used as a field, except replace #4 with 'a mutating method is never called')

Original issue: http://code.google.com/p/mutability-detector/issues/detail?id=18