Antonio Gallardo wrote:
On Vie, 14 de Enero de 2005, 16:59, Sylvain Wallez dijo:
Vadim Gritsenko wrote:
Antonio Gallardo wrote:
No problem, take your time. Just out of curiosity, what is yourPlease 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.
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.
What shared remote caches? Do you have that already? And the problem here is not having different *java* versions, but different *cocoon* versions using the same hypothetical remote cache. And that would seem a very bad thing to me to have different Cocoon version share their caches. Not only because of class versions, but also because different versions may also mean different sitemaps, different XSLs, etc, leading the cached content to be actually different for the different Cocoon instances.
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.
That's exactly the point: when do we have the probability that the pesistant cache is reused by a different version of Cocoon? Either during development or when a production machine is upgraded.
In both cases, the persistent cache *should be cleared*. Actually we should even to it within Cocoon.initialize().
So, back to the uid problem, such class version mismatches aren't to be considered as nominal conditions, as is the case with distributed applications. Cocoon is not a distributed system and is not supposed to have long-lived persistent data.
Furthermore, the cache is a *cache* and therefore the system doesn't require some data to exist there.
That's why I prefer not having uids, and not having to be careful about updating them or *maintaining* readObject/writeObject methods just for the exceptional condition of stop/updgrade/restart.
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.
Sorry, I should have missed that: when have we made such decision? Can you point me to the archives?
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!
Yes, but it is automatically generated for us, which is good as we don't need long lived serialized objects, and therefore don't have to consider class compatibility issues at the serialization level. Let just the JDK produce the uid for us and throw a nice java.io.InvalidClassException if ever, by mistake, we try to deserialize something that we should not.
Again, Cocoon isn't a distributed system and sharing serialized objects between different version (either across space or time) is not a concern for Cocoon.
<snip/>
I am also planning to add Read/Write Object methods on some of this classes.
That's precisely the additional job I want us to avoid to maintain.
Sylvain
-- Sylvain Wallez Anyware Technologies http://www.apache.org/~sylvain http://www.anyware-tech.com { XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
