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