Interestingly, if the behavior in this case was to write empty values on
the write side and read and discard on the read side, both the behavior
and the serialized format of java.util.Date would be identical to today;
though other pathological classes might be incompatible, they were
already in undefined-land.
On 02/14/2014 12:01 PM, David M. Lloyd wrote:
Yes, however given that the lack of reading/writing fields makes it
undefined *in general*, you can only say "the behavior is defined as
long as this undefined behavior is actually defined in this (risky)
manner".
Put another way, since the behavior of not reading/writing fields is not
defined, this class is then by spec not portable between JVMs (after
all, undefined behavior could mean anything at all). That's why I was
saying that the spec should define exactly what will physically happen
if you do this (from both the perspective of the "other end" of the
serialization API, *and* the wire protocol), even if it's considered
poor practice - because then at least you have guaranteed
interoperability (which becomes even more important with the knowledge
that JDK classes have this issue).
On 02/14/2014 10:31 AM, roger riggs wrote:
Hi David,
I would quibble that the serialized form of java.util.Date is defined.
The behavior is defined by the writeObject and readObject methods.
They write and read a time computed from and restored to the state of
the object.
Roger
On 2/14/2014 10:56 AM, David M. Lloyd wrote:
On 02/13/2014 11:38 AM, David M. Lloyd wrote:
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.
In the JDK, java.util.Date does not read/write fields. Perhaps others
as well. Given that the behavior is presently undefined, that means
the serialized representation of java.util.Date (and any other such
non-conforming classes) are also undefined.
--
- DML
