A previous anonymous poster commented regarding enhancement:
However, most seasoned programmers will cringe over class mutilation (or implementing PersistenceCapable manually).
Personally I agree that manually implementing PersistenceCapable would be an unlikely choice, although people should never-the-less know that they have that choice.
In my experience, perfectly seasoned and rationally-minded developers are actually taking the other approach. I've seen clients with complex systems gaining great productivity benefits through the combination of Ant, XDoclet and bytecode enhancement.
They put XDoclet comments into their domain classes which identify the persistence descriptor information relevant to that class. (Usually the defaults are fine, but the number of items grows if you're overriding default persistence attibutes, identifying persistence-capable superclasses, or specifying the O/R mapping to an existing relational schema) By locating these structured comments in the actual java source file for each class the information is more readily changed as the class evolves.
The Ant build script then includes a step to run an XDoclet task which parses the source code and builds the persistence descriptor XML file.
Finally, after Ant has done the compilation steps, it invokes the JDO enhancer, generating enhanced classes into a different directory structure from the location of the un-enhanced .class files.
Although a build structure such as this is non-trivial to establish, it results in a high degree of developer productivity.
One more thing about enhancement: remember that enhanced classes share the same "serialveruid" value as their un-enhanced counterparts. This means that is is possible to serialize instances of enhanced classes from one VM into another (client?) VM where only the un-enhanced classes are available. If you have manually implemented the PersistenceCapable interface, or used an automated source-code enhancer (as opposed to a bytecode one), then you will not have this deployment flexibility.
Kind regards, Robin.
Robin M. Roos