On 03/20/2015 09:31 AM, Peter Levart wrote:
On 03/20/2015 02:03 PM, David M. Lloyd wrote:
private static void altReadObject(ObjectInputStream in, FieldAccess
fieldAccess) throws IOException, ClassNotFoundException {
// the same as in readObject, but doesn't have direct
access to
instance state, so everything must go through FieldAccess API?
}
Yes.
An interesting aspect of this approach is that it deals with a problem
in the serialization spec [1] where it specifically says that
serializable classes should be reading/writing stream fields always,
and before reading/writing other data:
In section 3.4: "Either ObjectInputStream's defaultReadObject or
readFields method must be called once (and only once) before reading
any optional data written by the corresponding writeObject method;
even if no optional data is read, defaultReadObject or readFields must
still be invoked once."
In section 2.3: "Either ObjectOutputStream's defaultWriteObject or
writeFields method must be called once (and only once) before writing
any optional data that will be needed by the corresponding readObject
method to restore the state of the object; even if no optional data is
written, defaultWriteObject or writeFields must still be invoked once."
But classes (even JDK classes) often disregard this requirement,
relying on known implementation behavior and either reading/writing
optional data before fields or just not reading/writing fields at
all. So either the spec should be updated (I've tried to do this but
nobody seems to know how to modify this old content I guess) to match
behavior, or the spec should be enforced more strictly - however doing
the latter *will* break a lot of user code, *unless* an alternative
readObject method is introduced with the more strict enforcement. But
I guess even in this case, the spec should be updated to allow the
implementation behavior.
[1]
http://docs.oracle.com/javase/8/docs/platform/serialization/spec/serialTOC.html
I guess this would need an alternative writeObject method too, with more
strict enforcement, or not?
Sounds fine to me...
I don't know from the top of my head, but does the order of writing
optional data (before or after) fields, change the order of data emitted
in stream and does that order have to be respected when reading back in
readObject()?
Yes.
In that case, I guess, we would need an alternative
writeObject method too, with more strict enforcement of order. But I
think that having two different rules for old read/writeObject and
alternative read/writeObject would just confuse people. If current rules
don't present any problem (apart from being looser then specification
requires) then perhaps just specification should be updated.
Maybe.
--
- DML
