Make a immutable extension to a mutable object.

Question

I have a mutable object that i would like to extend into a immutable version. The problem is in the mutable object's constructor, because it calls a method that mutates it's fields. What is everyone's thoughts on the following 'pattern'/solution below?. While this works perfectly fine for my tests and I'm pleased with the results I have an issue with calling it an immutable extension because i don't know if i can guarantee the immutability of it. Also please note that I do not want to change the mutable object's code as it is a java.util class and that the example below is only an example.
public class MyMutableObject
    private int number;
    public MyMutableObject(){
        incrementNumber();
     * Mutates the current state!
    public void incrementNumber(){
        number++;
    public int getNumber(){
        return this.number;
public final class MyImmutableObject extends MyMutableObject
     * synchronized should take care of the thread safty.
    public static synchronized MyImmutableObject newInstance(){
        return new MyImmutableObject();
     * when true the class is immutable.  we will take advantage of
     * the default value of a boolean(false) in order to determine
     * its state.
    private final boolean sealed;
    private MyImmutableObject(){
        super();
        sealed = true;
    @Override
    public void incrementNumber() {
        if (sealed)
            throw new UnsupportedOperationException("Object is Immutable!");
        super.incrementNumber();
}

Answer 1

How is this functionally different from
public final class MyImmutableObject extends MutableObject {
    public MyImmutableObject() {
        super();
    public void incrementNumber()
    throws UnsupportedOperationException {
        throw new UnsupportedOperationException("Object is immutable");
I see no value in either the sealed variable or the factory constructor.
The synchronization, in particular, is a waste of time. Immutable classes
are thread-safe by definition. As for the variable, since MyImmutableObject
is final, and the only constructor seals it, there's no point.
I'd say your class does enforce immutability as written. I'm not
particularly fond of throwing exceptions when the immutable contract
is violated, but you don't appear to have many other options.
Also, ==tschodt