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] -------------------------------------------------
