0

If I implement the writeObject or readObject method, what would happen if I do not call defaultWriteObject()/defaultReadObject()? Will the class meta data not be written (class name, etc.), which is usually done during default serialization?

  1. If the meta data of the class is not written, then would having the class of the serialized object in the path of the JVM be still required during deserialization? Here's what happened when I tried this out - kept the class in the path when serializaing it but took it out during deserialzation:

Exception:

Exception in thread "main" java.io.StreamCorruptedException: unexpected block data
    at java.io.ObjectInputStream.readObject0(Unknown Source)
    at java.io.ObjectInputStream.defaultReadFields(Unknown Source)
    at java.io.ObjectInputStream.readSerialData(Unknown Source)
    at java.io.ObjectInputStream.readOrdinaryObject(Unknown Source)
    at java.io.ObjectInputStream.readObject0(Unknown Source)
    at java.io.ObjectInputStream.readObject(Unknown Source)
    at com.fiberlink.sample.JwtCreator.main(JwtCreator.java:28)

Why would java throw this exception? If I have the class in the path, this exception is not thrown. If the meta data of the class isn't even there, how does it do a cross check to see of the class is in the path?

  1. If the meta data is still written, who does that? I have implemented the writeObject method in my serializable class and am not calling the default methods. Where would the meta data come from?

Here's the serializable class that I wrote:

public class TestSerial implements Serializable
{
    private static final long serialVersionUID = 1L;
    public transient int a = 4;
    public String c = "ccccc";
    public String b = "bbbbb";

    private void writeObject(ObjectOutputStream os)
    {
        try {
            os.writeInt(a); // 3
        }
        catch (Exception e) {
            e.printStackTrace();
        }
    }

    private void readObject(ObjectInputStream is)
    {
        try {
            a = is.readInt();
            System.out.println(a);
        }
        catch (Exception e) {
            e.printStackTrace();
        }
    }
}
benka
  • 4,732
  • 35
  • 47
  • 58
user1968919
  • 153
  • 3
  • 13
  • Could you please add the code that throws this exception? – kraskevich Oct 03 '14 at 19:05
  • Please be precise in how you formulate your question: saying that you override writeObject/readObject is incorrect because these methods are not part of an interface or super class (and they are private at that). Your current formulation is confusing. – Lolo Oct 03 '14 at 20:01
  • @WilliamPrice, the purpose of that question was different. I'm trying to go a bit deeper into the matter - more specifically the inner workings of serialization in Java. – user1968919 Oct 03 '14 at 21:00
  • @Lolo edited the question. Now writing implemented instead of overriden. Thanks for pointing that out! – user1968919 Oct 03 '14 at 21:02
  • 1
    @user1968919 possibly because of this line from the _accepted answer_ to that question (emphasis mine): " If `defaultWriteObject` or `writeFields` is not invoked once prior to the writing of optional data (if any), then **the behavior of instance deserialization is undefined** in cases where the `ObjectInputStream` cannot resolve the class which defined the `writeObject` method in question." – William Price Oct 03 '14 at 22:06
  • @WilliamPrice Thanks for highlighting that. So that means,we really don't know what happens when don't call the defaultWriteObject? – user1968919 Oct 04 '14 at 12:42
  • 1
    If you pick a _specific JVM implementation and version_, dig deep in its source code, and figure out all the edge cases, then you _can_ "know what happens" and why. However, because the spec says the behavior is _undefined_, whatever answer you find probably isn't applicable in the general case. Your question becomes an academic interest but it's not of any practical use. – William Price Oct 04 '14 at 16:07

0 Answers0