Hi David,

Have you tried wrapping the Object(s) passed in a collections class like an
ArrayList, then merely pass the ArrayList, looking therefore for an
ArrayList on the other side?

Only when you iterate through the ArrayList after receiving it, the
unknown-classed object should then throw an exception of some sort,and you
might be able to try-catch it there, after the OutPutStreams have completed
their work?

HTH -Ike

It's a bit tricky to manage this.  If the two applications don't have a common
set of .class files, then you'll have to find some way to do one of two things:

a)  Only transmit objects which /are/ shared.  This may force you to convert
objects from one side or the other into some sort of neutral common form before
sending them.  Not too nice...

b) Use classloaders to share the code dynamically.  Also painful, but perhaps
not as bad.

Before getting into that, it's worth pointing out that RMI already has features
for doing this kind of thing for you, so if you haven't looked at RMI then it
might be worth doing so.

Anyway, concentrating on (b).  There are two issues here.

The first is classloaders, what they do, and how they work.  If you don't know
how to use classloaders, then now is the time to find out ;-)  Once you have
done, then you will understand how to use custom classloaders to control almost
every aspect of where an application looks for class definitions.

The second issue is how to tell the ObjectInputStream to use your custom
classloader.  That's a lot simpler -- it's just a matter of creating a custom
subclass of ObjectInputStream which overrides the definition of resolveClass().
In fact you might not even have to do that, if the class which uses the
ObjectInputStream was itself loaded by your custom classloader.

   -- chris