On Tue, May 17, 2005 at 03:54:54PM -0700, Jeremy Boynes wrote: > David Blevins wrote: > >On Sat, May 14, 2005 at 03:56:18PM -0700, Jeremy Boynes wrote: > > > >>And after all, one requirement Sun place on a JavaBean is that it > >>is Serializable. > > > >They do not require that the JavaBean is serializable bewteen > >versions of the class. That requirement and the problems it > >introduces are Geronimo's. > > The serialization contract goes into a lot of discussion on object > versioning, compatible and incompatible changes, and how the class is > responsible for maintaining that contract. A lot of the details are here: > > http://java.sun.com/j2se/1.3/docs/guide/serialization/spec/serialTOC.doc.html
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 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. > 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. 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. -David
