David Blevins wrote:

Yes, I've read that spec as well as written a clean-house implementation of ObjectOutputStream:

http://cvs.openejb.org/viewrep/openejb/openejb1/modules/core/src/java/org/openejb/util/io/ObjectOutputStream.java


The problem is usually on the input side as the old version of the object is just writing its data out.



I know exactly how much room for error there is as well as the amount forethought and code required to guarantee even a small amout of future compatibility. Using SUIDs alone does not cut it. I'm not arguing it's impossible, I'm arguing that it's unrealistic and unreliable at best.


I think you're looking at it backward - without a crystal ball you don't know what future versions of the class will look like. It is the responsbility of the evolved class to handle upgrading older data.


This is a semantic problem that applies whatever form the infoset takes, whether that is XML or a byte stream.


Having said that, it is also worth taking note of David Jencks's comments that Serialization only applies to GBean attribute values
and not to the implementation classes or to references between
GBeans.


As he pointed out with ActiveMQ, problems appear to be occuring not
 because the attribute values are not serializable but because what
 attributes are present is incompatibly changing. This would occur
with any of the mechanisms above.


The major technical difference between xml data and object
serialization data is that xml data can still be parsed even if the
schema has changed. The same is not true of serialized object data.

Why? You can parse a stream of bytes as easily as you can parse a stream of characters. Whether you can use the result of the parse will depend on the semantic content of the new infoset - you can create incompatible XML schemas as well.


As David Jencks has shown, we can gain a tremendous amount of past
and future compatibility by reading in old xml documents and
upgrading them to the current versions.


Two factors here: 1) the infoset for those XML documents was carefully crafted by the expert groups specifically so that it could be upgraded. If they had not then we would need dual implementations - one for the old, one for the new.

2) the upgrade process is still fairly expensive

--
Jeremy

Reply via email to