I see a general problem I call demoting and promoting objects.

A Dog gets promoted to a Dalmatian object by gaining extra
Dalmatian-specific fields.

A Dalmatian gets demoted to Dog object by stripping off its Dalmatian
specific fields.

The object itself is unchanged. You create a new modified object and
discard the old one.

Why would you do such a thing?

1. to strip and object down for export, serialisation, or RMI
transport.

2. to strip an object of confidential information before handing in
on.

3. to avoid having to give confidential code used to process, edit or
construct your objects when all they will do is view them.

The way you did the equivalent thing in COBOL was a MOVE CORRESPONDING
that copied field by field. In Java traditionally you do the same
thing writing code guaranteed to stop working the instant any of the
class structure changes.

How might you handle this more elegantly?

1. a class parser then generates code to do the move-corresponding.

2. Java gain some feature to easily create copy constructor so you
could say:

something like:

/**
* cloning constructor
* Makes a Dog out of any Dog object including a Dalmatian object.
* The new object will have only the Dog fields and methods, even if
* cast back to the original type.
*/
Dog ( Dog ) { Magic.copy(); }

Where copy is some magic JNI or new Java feature.

The assembler code theoretically could be just a block byte move of
dog's object size bytes -- extremely fast compared with field by field
copy.
.