Greg, if you could still ctrl-1 through some of these couurences, that would be great. I agree on the subject of the generated classes, so let's create a new issue at http://jira.codehaus.org/browse/CASTOR and let#s assign it to the XML sub-project.
Thanks Werner PS Speaking of which, fancy testing some distributed caches ... ;-) ? -----Ursprüngliche Nachricht----- Von: Gregory Block [mailto:[EMAIL PROTECTED] Gesendet: Montag, 01. August 2005 11:36 An: [email protected] Betreff: Re: [castor-user] Missing serialVersionUID in Castor generated classes? Yeah, at some point, I'll go through andn cmd-1 some UIDs into those in Eclipse; won't really solve the big problem, tho, which is that Castor's own classes should (IMO) generate code that obeys the basic rules for UIDs in classes - that two classes which serialize to the same representation should have the same UID, to ensure that serialized versions can be loaded in. That's going to become a *lot* more valuable once people start using serializable caches, and people start trying to upgrade live applications running distributed caching, possibly with persistent disk caches, on their live services - who may suddenly find that the entire live service contains a set of cached information which simply isn't readable anymore for no reason other than that they simply recompiled their app. On 26 Jul 2005, at 20:38, Werner Guttmann wrote: > Greg, > > I wasn't particularly referring to generated classes per se. It > just occurred to me - when replying - that there actually is a lot > of classes out there in src codebase that are Serializable, but > don't carry a UID. > > Werner > > On Tue, 26 Jul 2005 12:25:16 +0100, Gregory Block wrote: > > >> In the code generator? I'm not so keen on changing things I don't >> actually use in my projects - and code generation pretty much falls >> at the bottom of the list of things I might ever want to use. :) >> >> Code generator *should* generate UIDs; that it does not is no better >> or worse than generating code that generates lots of warnings... but >> in order for Code Generator to generate those UIDs, there's one >> fundamental question worth asking: >> >> >> Should CG always generate the same UID for a given list of fields, >> types, and orders? In other words, should re-generating the exact >> same schema result in the same UIDs? If people have a build process >> that involves every clean build in completely re-generating those >> classes, then they will essentially break their own serialization >> with every major version. >> >> >> Answer, IMO: YES. This means that UID generation won't resemble >> Java's own mechanism, but will generate a long based on (probably) a >> hash of the class name, package name, field member types, and field >> names, in order. Changes which would not result in a change to the >> hash will not get recognized; this would, however, mean that UIDs >> will be based on the actual fields present in the XML, and XML >> changes will auto-modify the UID to break serialization on that >> class. >> >> Downside: Well, XML changes auto-modifying the UID sound awful, >> because it means you can't manually handle that change in serialized >> form and provide an implementation for de-serializing old serialized >> versions of a class; on the other hand, these are *generated* >> classes; if you wanted manual control, you shouldn't have generated >> in the first place. >> >> Downside: Unless the UID generation also includes some version >> information from Castor, later versions of castor, which may generate >> code differently, will not break that UID. Arguably, the castor >> build or version number should be included in UID generation hash. >> >> >> As for doing it the way Eclipse does: Eclipse compiles the class, >> runs the JVM to generate the serial version UID, and then inserts the >> serial version UID back into the Java source. This is doable if, for >> example, you would like to include a dependency on the Eclipse java >> compiler with Castor - at which point, we can then take the source >> code, compile it, run java, and then using the AST tree that >> Eclipse's compiler provides, insert the correct node into the tree, >> resave the AST tree as java source on the disk, and continue. >> >> Whether or not the Castor developers wish to reconstruct their source >> generator on Eclipse AST trees is, of course, debateable. :) OTOH, >> it works just fine for the Tomcat folks. >> >> On 24 Jul 2005, at 21:24, Werner Guttmann wrote: >> >> >>> Mind supplying us with a patch .. ;-) ? Given that Eclipse has some >>> nice >>> quick fixs in this area, this should not be too hard to achieve. >>> >> >> >> ------------------------------------------------- >> If you wish to unsubscribe from this list, please >> send an empty message to the following address: >> >> [EMAIL PROTECTED] >> ------------------------------------------------- >> >> > > > > > > ------------------------------------------------- > If you wish to unsubscribe from this list, please > send an empty message to the following address: > > [EMAIL PROTECTED] > ------------------------------------------------- > > ------------------------------------------------- If you wish to unsubscribe from this list, please send an empty message to the following address: [EMAIL PROTECTED] ------------------------------------------------- ------------------------------------------------- If you wish to unsubscribe from this list, please send an empty message to the following address: [EMAIL PROTECTED] -------------------------------------------------
