It would be interesting to see a JDK happen where all these backwards compatibility quirks are ignored, and raw performance is chased instead. A thousand of these little gains can really add up over decades. In this case there was a workaround it seems, but it feels a bit contrived to me ('missing fields are ok'?).
> but it feels a bit contrived to me ('missing fields are ok'?)
IIUC, the idea is that an object can be safely deserialized if its field set upon deserialization is a strict subset of its field set upon serialization. I think that's a sound approach, it's in line with (the second part of) the robustness principle: "be liberal in what you accept".
It would be interesting to see a JDK happen where all these backwards compatibility quirks are ignored, and raw performance is chased instead. A thousand of these little gains can really add up over decades. In this case there was a workaround it seems, but it feels a bit contrived to me ('missing fields are ok'?).
> but it feels a bit contrived to me ('missing fields are ok'?)
IIUC, the idea is that an object can be safely deserialized if its field set upon deserialization is a strict subset of its field set upon serialization. I think that's a sound approach, it's in line with (the second part of) the robustness principle: "be liberal in what you accept".