On 02/13/2014 10:29 AM, Chris Hegarty wrote:
On 12 Feb 2014, at 15:24, David M. Lloyd <david.ll...@redhat.com>
wrote:
That's a quote from the serialization spec. I take it to mean,
"Don't write fields and everything might go to hell". In practice,
if the reading side doesn't read fields, things end up more or less
OK, as evidenced by various classes in the wild. But it's not hard
to imagine a scenario in which a class change could cause protocol
corruption.
I think the specifics of the quote relate to this kind of class
change; in particular, if a class is deleted from the hierarchy on
the read side, and that class corresponds to the class that had the
misbehaving writeObject, I suspect that things will break at that
point as the read side will probably try to consume and discard the
field information for that class, which will be missing (it will
start reading the next class' fields instead I think).
Yes, possibly. And who knows what fields/values may be read and
mistaken for the wrong object in the hierarchy. So ‘undefined'
behaviour seems right to me.
I think the behavior is well-defined, just "bad", which is my point. If
the exact current is spec'd out as-is then at least we can be assured of
the same bad behavior across implementations. If the behavior is
changed such that fields are read/written but discarded, without
updating the spec, then the "undefined" behavior at least becomes safer.
If the behavior is changed, *and* the spec is updated, then we get
both benefits, but at the cost that all previous implementations will
not be compliant with the spec.
All options seem to have a cost though.
--
- DML
