You can still serialize the object.

Let us say you have a class Foo with a member Baz that you don't control.

public class Foo
{
  transient private Baz baz;
  ...
}

Making the Baz element transient simply means you have to manually serialize
and deserialize the Baz object.  The fact that Baz is not Serializable is
moot; no one is using Baz to try.  That could be complicated if Baz is a
collection itself, but let's assume it's some sort of fairly uncomplicated
class with serializable attributes.

<http://java.sun.com/javase/6/docs/api/java/io/Serializable.html>
explains to use

 private void writeObject(java.io.ObjectOutputStream out)
     throws IOException;
and

 private void readObject(java.io.ObjectInputStream in)
     throws IOException, ClassNotFoundException;

You write these methods to [de]serialize the well-known parts of Baz (untried,
untested):

 private void writeObject(java.io.ObjectOutputStream out)
     throws IOException
 {
  out.defaultWriteObject();
  out.writeObject( baz.getIntegerValue() );
  out.writeObject( baz.getStringValue() );
 }

 private void readObject(java.io.ObjectInputStream in)
     throws IOException, ClassNotFoundException
 {
  in.defaultReadObject();
  baz.setIntegerValue( (Integer) in.readObject() );
  baz.setStringValue( (String) in.readObject() );
 }

Then it matters not that Baz is not Serializable.

Fairly easy, as long as each type knows how to copy itself.  It gets tricky
when you have cycles in your reference graph, as you need to track copying
objects and references to objects separately.  It's here that serialization
starts to look tempting.

No, you just need to make it transient and implement a readObject and
writeObject method that properly handles saving and restoring it (if needed).
--
Mark Rafn    dagon@dagon.net    <http://www.dagon.net/>