As we will see in the next installment this is how J2EE invocation on remote interfaces go around the problem even when you call them within the server. However, the client that receives the class will actually load the class locally (with its own class loader) and then incorporate the values from the object stream. But that requires that the client has a compatible class defintion available and if not deserialization will fail. In the case you have a compatible version the class behind the newly created instance is NOT (if the client uses a different class loader) compatible to the original class because the two class types have different class loaders. Thus to send the data back you need to serialize/deserialze the class again.
In the next part of this article series I will explain a little bit more in detail how J2EE deals with multiple class loaders and talk about serilization/deserialization.
Nevertheless I do not have a more elegant solution to propose even thought I would like to have a possiblity in Java to force a upcast as long as the class types are compatible to avoid wasting a lot of time.