geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeremy Boynes <>
Subject Re: API and serialization compatibility, was: Build Failure
Date Sun, 15 May 2005 02:51:36 GMT
Dain Sundstrom wrote:
> On May 14, 2005, at 3:56 PM, Jeremy Boynes wrote:
>> Dain Sundstrom wrote:
>>> Tim,
>>> As you point out, the problem of serialization is far reaching.    
>>> Basically, we need to get every project included in Geronimo to  buy  
>>> into serialization stability, and to my knowledge there are  no  
>>> projects in Geronimo that today have committed to this.  In  
>>> addition,  Geronimo itself is does not support serialization  
>>> stability, and if  we choose this path, we must clean up our own  
>>> house by verifying  every serializable class is set up for upward  
>>> compatible  serialization.  This is by no means an easy task, but  I 
>>> think before  we ask something of other project we are aware of  the 
>>> effort involved  in what we are asking.
>>> Alternatively, we could choose to do like Sun did with swing and  
>>> give  up on serialization and use an xml based storage mechanism  
>>> based on  Java Beans rules.
>> The issue is not the implementation (serialization vs. XML) but the  
>> compatibility of the information set between versions.
> Actually implementation IS the issue.  If we choose serialization,  the 
> other projects must agree to implement Serialzable and maintain  upward 
> compatibility.  If we choose an xml strategy like Sun's  JavaBeans xml 
> stuff, the other projects must only agree to maintain  compatibility of 
> public property names (i.e., the getter and setter  names not the 
> private field names) and constructor arguments.  This  is much smaller 
> task to ask of other projects, since most are already  providing IoC 
> compatible services.

Surely if a project is not prepared to maintain compatibility for 
Serializable objects it is not going to maintain property compatibility 
either. In fact, given the flexibility of the JavaBean model (well not 
strictly as JavaBeans are meant to be Serializable) and the lack of any 
indication of persistence (e.g. that it does not implement a tag 
interface or have a marking annotation) I would argue that property 
drift was more likely as there would not be anything to indicate to a 
developer that compatibility would be required.

>> As David Jencks has pointed out elsewhere, we do not need every  
>> project to commit to serialization stability everywhere, just in  the 
>> classes that are being used in GBean attributes. If they do  great; if 
>> they don't we just don't use those classes as attribute  values and 
>> handle reconstruction ourselves.
> I agree with the statement, but we have only pushed the problem down  
> one level.  

Indeed, but pushing it down that level is critical as it lets the GBean 
implementation handle the reconstruction of the underlying object graph.

Most simple attributes have Serializable values. No problem.

Any project that tags its classes as Serializable ought to handle the 
version drift. If it indeed does so, no problem. If it does not, then we 
simply treat the values as if they were non-Serializable.

If the values are non-Serializable then the project needs to define how 
the objects can be persisted; hopefully that includes a way to handle 
version drift. The GBean can use that mechanism to convert the 
non-Serializable object graph to/from its persistent form stored in a 
Serializable object such as a byte[] or char[]

Let's be clear, there are several issues here:
1) persistent form. Serialization provides a very low-overhead, high-
    performance solution and can be used to underpin higher level

2) object version skew. Again Serialization provides clearly documented
    ways to handle that.

3) adoption. Serialization is easy to implement especially for mature
    objects with little version skew. XML JavaBean persistence is not
    widely used as the external XML format is not designed for human
    modification. XML in conjuction with a persistence schema is more
    widely used but carries high overhead especially when schema
    validation is used.

4) configuration version skew. This is handled by the configuration
    management system as discussed elsewhere.

The current model provides a very effective, high-performance, 
low-overhead configuration persistence mechanism that can be extended 
with higher level mechanisms where appropriate.


View raw message