JavaMemoryModel: Semantics of final and fixing the immutable String problem

From: David Holmes (
Date: Tue May 15 2001 - 19:27:28 EDT

The semantics of final, as described in "Semantics of Multithreaded Java",
leaves me confused as to how the proposed semantics fix the immutable String
problem. It is unclear whether the correct use of final with immutable
objects, is that the reference to shared immutable objects must be final, or
whether the immutable object must utilise final fields.

If it is the shared reference that must be final, then the user's of
immutable objects are responsible for ensuring the immutability property.
This means that if the user does the wrong thing then immutability can still
be compromised. This is not a satisfactory "solution".

If it is the immutable object that must use final fields, then I don't see
how this can work in general unless all of the fields of the object are
final. In the String example from the paper we would need the char[], length
and offset fields to all be final. This sounds like the old use of volatile
- it only really works properly if everything is made volatile. This too
seems an impractical solution.

Could someone clarify please.

David Holmes
JavaMemoryModel mailing list -

This archive was generated by hypermail 2b29 : Thu Oct 13 2005 - 07:00:31 EDT