Final members in nonimmutable objects - thread safe?

[Warren Dew]

So, the following is thread safe due to immutability:

public class Immutable
{   private final String one;
    private final String two;
 
    public Immutable(String a, String b)
    {   one = a;
        two = b;
    }
    public String getOne() {return one;}
    public String getTwo() {return two;}
}

And the following is safe due to synchronization:

public class Synchronized
{   private String one;
    private String two;
 
    public Synchronized(String a, String b)
    {   synchronized (this)
        {   one = a;
            two = b;
        }
    }
    public synchronized void setOne(String value) {one = value;}
    public synchronized String getOne() {return one;}
    public synchronized void setTwo(String value) {two = value;}
    public synchronized String getTwo() {return two;}
}

Now consider the following class:

public class Mixed
{   private final String one;
    private String two;
 
    public Mixed(String a, String b)
    {   synchronized (this) {two = b;}
        one = a;
    }
    public String getOne() {return one;}
    public synchronized void setTwo(String value) {two = value;}
    public synchronized String getTwo() {return two;}
}

Two questions:

1. Is this thread safe?

2. Can someone point to the relevant part of the Java Language Specification?

The reason I ask is that I can only find comments about "final" ensuring thread safety in the context of immutable objects, by ensuring a store barrier before exiting the constructor. Is such a barrier ensured even if only some of the member data is final? Does the barrier come at the end of the constructor, or might it occur before the initialization of nonfinal members?

(Edited to remove an unintended "synchronized" before the accessor of the final variable in the Mixed class.)
[ October 22, 2008: Message edited by: Warren Dew ]

[Mike Simmons]

1. Yes.

2. JLS 17.5 discusses the effect of using final using an example class that has one final field and one nonfinal field. The class may look immutable, but it's not, because of the nonfinal field. Nonetheless the discussion makes the point that the final field is thread-safe, even though the nonfinal field is not. They don't specifically talk about synchronization here, but the point remains that you can evaluate the thread safety of different fields separately, and use different strategies for each.