Question

The Java language spec defines semantics of final fields in section 17.5:

The usage model for final fields is a simple one. Set the final fields for an object in that object’s constructor. Do not write a reference to the object being constructed in a place where another thread can see it before the object’s constructor is finished. If this is followed, then when the object is seen by another thread, that thread will always see the correctly constructed version of that object’s final fields. It will also see versions of any object or array referenced by those final fields that are at least as up-to-date as the final fields are.

My question is – does the ‘up-to-date’ guarantee extend to the contents of nested arrays, and nested objects?

In a nutshell: If one thread assigns a mutable object graph to a final field in an object, and the object graph is never updated, can all threads safely read that object graph via the final field?

An example scenario:

1. Thread A constructs a HashMap of ArrayLists, then assigns the HashMap to final field ‘myFinal’ in an instance of class ‘MyClass’
2. Thread B sees a (non-synchronized) reference to the MyClass instance and reads ‘myFinal’, and accesses and reads the contents of one of the ArrayLists

In this scenario, are the members of the ArrayList as seen by Thread B guaranteed to be at least as up to date as they were when MyClass’s constructor completed?

I’m looking for clarification of the semantics of the Java Memory Model and language spec, rather than alternative solutions like synchronization. My dream answer would be a yes or no, with a reference to the relevant text.

Updates:

• I’m interested in the semantics of Java 1.5 and above, i.e. with the updated Java Memory Model introduced via JSR 133. The ‘up-to-date’ guarantee on final fields was introduced in this update.

Answer 1

In this scenario, are the members of
the ArrayList as seen by Thread B
guaranteed to be at least as up to
date as they were when MyClass’s
constructor completed?

Yes, they are.

A thread is required to read memory when it encounters reference for the first time. Because hash map is constructed, all entries in it are brand new, then the references to objects are up-to-date to what they were when the constructor has finished.

After that initial encounter, the usual visibility rules apply. So, when other thread changes non-final field in the final references, the other thread may not see that change, but it still will see the reference that came out of constructor.

In reality, it means that if you do not modify final hash-map after the constructor, its contents are constants for all threads.

EDIT

I knew that I’ve seen this guarantee somewhere before.

Here is a paragraph of interest from this article that describes JSR 133

Initialization safety

The new JMM also seeks to provide a
new guarantee of initialization safety
— that as long as an object is properly constructed (meaning that a
reference to the object is not
published before the constructor has
completed), then all threads will see
the values for its final fields that
were set in its constructor,
regardless of whether or not
synchronization is used to pass the
reference from one thread to another.
Further, any variables that can be
reached through a final field of a
properly constructed object, such as
fields of an object referenced by a
final field, are also guaranteed to be
visible to other threads as well. This
means that if a final field contains a
reference to, say, a LinkedList, in
addition to the correct value of the
reference being visible to other
threads, also the contents of that
LinkedList at construction time would
be visible to other threads without
synchronization. The result is a
significant strengthening of the
meaning of final — that final fields
can be safely accessed without
synchronization, and that compilers
can assume that final fields will not
change and can therefore optimize away
multiple fetches.