Some object serialization problems for discussion(1)-ObjectOutput Stream

[Wu, Gansha]

We have tested some Classpath serialization mechanisms with ORP providing 
complementary
native implementations. We found some problems in 
ObjectInputStream/ObjectOutputStream/
ObjectStreamClass/Throwable classes.
Here is the first of the series.

1. About ObjectOutputStream
     Considered the patched writeObject:
public final void writeObject (Object obj) throws IOException
 {
   ... ....
    try
    {
      isSerializing = true;
      boolean replaceDone = false;

      drain ();

+    Object replacedObject = null;                        <- Comment 1
     
      while (true)
      {
-       Object replacedObject = null;                     <- Comment 1

        if ((replacementEnabled || obj instanceof Serializable)
            && ! replaceDone)
        {
          replacedObject = obj;
          ... ...
          replaceDone = true;
          continue;
        }
        ... ...
        if (replaceDone)
          assignNewHandle (replacedObject);
        else
          assignNewHandle (obj);
                ... ...

        throw new NotSerializableException (clazz.getName ());
      } // end pseudo-loop
    }
    catch (IOException e)
    {
+      if(e instanceof NotSerializableException ){   <- Comment 2
+       throw e;
+      }
      realOutput.writeByte (TC_EXCEPTION);
      reset (true);

      try
      {
        writeObject (e);
      }
      catch (IOException ioe)
      {
        throw new StreamCorruptedException ("Exception " + ioe + " thrown while 
exception was being written to stream.");
      }
      ... ...
  }

Comment 1:
      We should move the declaration "Object replacedObject = null;" out of 
while loop, orelse in the next loop, replacedObject is reset to null, but 
replaceDone remains true, system will crash here:
          assignNewHandle (replacedObject); //replacedObject is a null object
Comment 2:
     We add some extra stuff in the "catch (IOException e)", consider the 
snariso:
        a. because the object is not serializable, so run to "throw new 
NotSerializableException (clazz.getName ());";
        b. because NotSerializableException inherits IOException indirectly, 
this exception is caught, and the exception object is serialized, but it's not 
reasonable, the exception should be caught by application logic.
     So I think a more check should be performed.
     BTW, I wonder if catching IOException is feasible here, because most of 
cases if real IOException happens, further serialization will fail again. So I 
think we might refine the exception handling here (other more specific 
exceptions).