clone won't do this for you. A shallow copy will still have references
to the same underlying objects, so if you change a mutable object in
the cloned one, the original one will be updated too.

It is up to you what a clone() method implementation does. If you need a
deep copy, implement clone() that way.

Since you have to implement clone() in your class it will do almost
whatever you want. Almost, because the tricky part is that if you need
to call the clone() methods of existing objects (e.g. collections) or
your superclass, you need to know how these methods are implemented. If
these existing clone() methods only provide a shallow copy, you need to
construct a deep copy of objects in your own code.

You can only do this if the APIs of the existing classes allow yo to
peek at enough of their internal state to construct a deep copy. If they
don't, you probably get enough insight when you subclasses the
particular classes. If the particular classes are final you are in
trouble. Then it would be time for some ugly reflection hack or for
betting on serialization.

/Thomas

   You might want to look into making your GameState objects into something
immutable, so as to sidestep the whole issue alltogether. Have it work like
BigInteger or String, such that when you perform an operation (such as "move
player 1 forward 1 square"), rather than modifying the current GameState, it
returns a new GameState object representing the new move.

   - Oliver

On Wed, 22 Mar 2006 14:04:47 GMT, Colin Hemmings
<colin.hemmings1@ntlworld.com> wrote, quoted or indirectly quoted
someone who said :

if you serialize an object, you get a deep copy. If you restore it,
you have an reasonably independent clone. Some of the strings might be
common, but that won't cause trouble.

It is an easy way to get a deep copy, albeit with a high overhead.

see http://mindprod.com/jgloss/serialization.html