Date class cannot be serialized from JDK11 to JDK8 about orb HOT 1 CLOSED

After adding unit tests, I have a better idea of the underlying issues.

With the new tests guiding me in reading the code, I think I know understand the problem and how to fix it.

1. Custom Java serialization provides three options, which class coders may mix and match: (a) a call to defaultWriteObject / defaultReadObject replicates the default behavior of serializing all serial, non-transient fields, (b) the use of the persistentSerialFields field allows specification of which of the fields (including non-existent ones) are serialized, and ( c) the code may also call the read/write methods directly on the object streams,
2. The Java-to-IDL spec considers that last option to be “optional” data, and the first two “default” data.
3. If the class is serialized using serial format 1, it behaves roughly as does native serialization; that is, the code may serialize and deserialize fields in any order it likes.
4. If the class is serialized using serial format 2, as it seems to be in many cases, the “optional” data is written into an extra object in the stream, whose type is a modification of the original class. I’m not sure what happens if any “optional” data is written before the “standard” data.
5. If the class invokes one of the methods to send “default” data, it also sets a bit in the encoding, indicating that this has happened, so the receiver can anticipate the presence of that default data. That seems kind of backwards, as it is the optional data that we really want to know about.
6. To try to sort all of this out, the input stream maintains a state machine which makes a number of assumptions, most importantly that if the sender indicates that it is sending default data, the receiver will call the corresponding method. That is not actually true in our Date case, since the JDL11 implementation calls both, and the JDK8 implementation calls neither.
7. There are actually a few other issues with the state machine, which assumes that a call to writeObject will always be matched by a call to readObject.

So the solution is going to be to replace the state machine in InputStreamHook with one that depends on the contents of the encoding and the steps taken to read it, rather than the steps used to write it.

from orb.