public APIReadOnlyPoint asReadOnly(APIReadWritePoint point) {
return(point);
}

So this raise the question of the meaning of immutable objects.
Immutable objects are under no condition modifiable. Best examples are the object representations of primitives (Integer, Boolean, etc.) and String.
JDK 1.3 could gain a huge performance gain by caching all strings and string creation and comparision was almost done in no time.

It is really nice to see what is possible with generics as Stephan demonstrated, but for this case it would rather be advisable to keep things simple and just have two different classes: One mutable and one immutable if really needed.

public interface Point
{
int getX(); int getY();
}

public class ImmutablePoint implements Point
{
private int x;
private int y;
public int getX(){return x;}
public int getY(){return y;}

public ImmutablePoint(int x1, int y1)
{
x=x1;y=y1;
}

public MutablePoint mutablePoint()
{
return new MutablePoint(x,x);
}
}

public class MutablePoint implements Point
{
protected int x;
protected int y;

public int getX(){return x;}
public int getY(){return y;}

public void setX(int x1){x=x1;}
public void setY(int y1){y=y1;}

public MutablePoint(int x1, int y1)
{
x=x1;y=y1;
}

public ImmutablePoint immutablePoint()
{
// we could here also lookup in a cache for a immutable object representing the Point and return only this instance.
return new ImmutablePoint(x,y);
}
}

public APIReadOnlyPoint getPoint();

The users of that method know that they’re getting a point that they cannot call the setters on, and the compiler won’t let them. No chance of exceptions being thrown.

public interface APIReadOnlyPoint {
public T getX();

public T getY();
}

public interface APIReadWritePoint extends APIReadOnlyPoint {
public void setX(T x);

public void setY(T y);
}

public class ReadOnlyPoint implements APIReadOnlyPoint {
protected T x;
protected T y;

public ReadOnlyPoint(final T x, final T y) {
this.x = x;
this.y = y;
}

@Override
public T getX() {
return x;
}

@Override
public T getY() {
return y;
}
}

public final class ReadWritePoint extends ReadOnlyPoint implements
APIReadWritePoint {
public ReadWritePoint(final T x, final T y) {
super(x, y);
}

public ReadWritePoint(final ReadOnlyPoint point) {
super(point.getX(), point.getY());
}

@Override
public void setX(final T x) {
this.x = x;
}

@Override
public void setY(final T y) {
this.y = y;
}
}

The big advantage of immutable Objects is that they are immutable and their state will not change. Otherwise you have to take care about synchronization and the java memory model.
So your suggestion will break the immutable contract.

I would have expected to get a new mutable object by changing to mutable. By the I would also expect to be able to have the possibility to get a immutable version from the mutable object.

So the makeMutable method needs a modification:
# public MutablePoint makeMutable() {
# return new DefaultPoint(x,y);
# }

Anyway, the DefaultPoint ist not really an immutable object, so it is not the best practice to use this kind of code and rely on the immutablity of the point.

With Qi4j I also would model the mutable state as a different concern.

http://www.jroller.com/rickard/entry/qi4j_status_report

point() is a factory (Fluent Interface style), see the method in DefaultPoint:


public Point point(int x, int y) {
return new DefaultPoint(x,y);
}


For more code this could be packaged into a new Object PointFactory oder PointBuilder.