On Vie, 14 de Enero de 2005, 16:59, Sylvain Wallez dijo: > Vadim Gritsenko wrote: > >> Antonio Gallardo wrote: >> >>> Please give me a little time to fix all the serialization changes. I am >>> currently using the BRANCH head in development this version and I am >>> checking if everything is working good. >>> >>> Anyway this could not harm. It is just a line on each class and we can >>> remove them if not needed before releasing. >> >> >> No problem, take your time. Just out of curiosity, what is your >> scenario which requires serialization? > > Yes, please explain, Antonio. > > Also, and we discussed this already not long ago [1], serial uid is > useful for long-lived serialized objects where there is a chance that > the class changes between serialization and deserialization. What in > Cocoon justifies this?
Shared remote cache. In some cases, they can use diferent java versions across machines and the troubles can be raisen. > Furthermore, Niclas' explanation that having a serialVersionUID leads to > newly added fields to have no value seems particularily dangerous to me > if we don't take special care about this as it can lead to weird errors. Nope. Because as you explained in your mail, we are not persisting for too long time. We will not take an "obscure failure" error. The weird errors are on the code without serialversionUID, because if you already have a Object cache cache and add a method to a serialiable class class there start the problems. > So I am -1 on adding serialVersionUIDs to Cocoon classes unless there is > a good reason for this. First, I am just trying to close posible "collateral damages". I am just adding the points over the "i"es here. If we have made the decisions to serialize some classes, we need to finish the work to avoid potential problems. And this is what I am doing now, just trying to close this doors by assuring that the serialization is done as is recommended by people that has more years working in java than me. What I understood is: If the class implements the Serializable interface, but does not define a serialVersionUID field then a change as simple as adding a reference to a .class object will add synthetic fields to the class, which will unfortunately change the implicit serialVersionUID (e.g., adding a reference to String.class will generate a static field class$java$lang$String). Also, different source code to bytecode compilers may use different naming conventions for synthetic variables generated for references to class objects or inner classes. We need toconsider adding an explicit serialVersionUID to ensure interoperability of Serializable across versions. Then reading from Effective Java from Joshua Bloch pag 214, 2nd paragraph: <snip> A simple example of the constraints on evolution that accompany serializability concerns stream unique identifiers, more commonly known as serial version UIDs. Every serializable class has a unique identification number associated with it. </snip> That means that no matter we do we already have one there! <snip> If you don't specify the identify the identification number explicitly by declaring a private static final long field name called serialVersionUID, the system automatically generates it by applying a complex deterministic procedure to class. The automatically generated value is affected by the class's name, the names of the interfaces it implements, and all of its public and protected members. If you change any of this things in any way, for example, by adding a trivial convenience method, the automatically generated serial version UID changes. If you fail to declare an explicit serial version UID, compatibility is broken. </snip> I am also planning to add Read/Write Object methods on some of this classes. Best Regards, Antonio Gallardo
