This post originated from an RSS feed registered with Java Buzz by Norman Richards. Original Post: Is XDoclet needed? Feed Title: Orb [norman richards] Feed URL: http://members.capmac.org/~orb/blog.cgi/tech/java?flav=rss Feed Description: Monkey number 312,978,199 Latest Java Buzz Posts Latest Java Buzz Posts by Norman Richards Latest Posts From Orb [norman richards]

Javid Jamae asks Is XDoclet needed? It's a good question. There's no doubt that XDoclet is a useful tool, but should it be? Is the need for code generation universal or is it just a tool to deal with the rigid constraints of the frameworks we work with. Javid asks why we have to settle for JavaDoc instead of embedding our metadata into the code using standard language constructs and frameworks. (I assume he is thinking of a JSR 175 like mechanism)

XDoclet does a lot more than just generate deployment descriptors. Think about an EJB world where you may be making a code generation sandwich, generating both the interface to the bean and then generating a subclass that provides default implementations of the EJB lifecycle methods. You might be generating value objects, which requires complex logic to shuttle data from the beans to the VOs. A lot of this is really tedious work like writing a proper equals() method and tracking whether or not values of been changed. That's really just the beginning, but there's an awful lot of actual code that that can get generating if you use XDoclet to the fullest. It's true that some of this shouldn't be necessary. A more dynamic system should be able to shuttle values from a bean to a VO and you shouldn't really need all those interfaces. But a dynamic system can only take you so far and you do need actual class files at some point.

Deployment descriptors aren't always overkill. Deployment information can't always be locked at development time. Components often need to be replaced, renamed or reconfigured at the customer site when deploying on their application server. Separating deployment information from the code is a very important feature of a component system. If the deployment details are locked into the source code, the deployment guys would need to edit the source and rebuild. I don't know about you, but as a developer, I find that very scary. Many projects are done with only one deployment in mind. Many are done with the idea that what we deliver is what we deliver and everything is locked in by the developers. But not all are, and having deployment descriptor outside of the code provides a lot of flexibility.

The deployment descriptor paradox. I like the flexibility of deployment descriptors, and I like keeping deployment details separate from the code. At the same time, I like keeping my deployment values in the code. I don't like to duplicate information. ("don't repeat yourself") I don't like having information in multiple classes and in an external file when I'm working with it. From that perspective XDoclet is a very elegant solution. You can keep all your information together in the source code for development purposes. But when you deliver the system the deployment descriptors are separated out for the services team to work with. It's the best of bost worlds.

JavaDoc vs. language construct. Suppose you had a JSR 175 type system that let you express your information, and imagine an XDoclet like generator could generate from it. You could get strongly typed metadata and great IDE support in maintaining yo 1000 ur metadata. The thought is appealing, but I'd point out that the XDoclet javadoc comment approach has at least one nice advantage: the ability to do compile time expansion. XDoclet can be your preprocessor. Because XDoclet works outside of the compiler at the level of your build tool, it can perform expansion of properties based on Ant properties. I can't stress enough how useful it is in the development process to be able to switch out configurations by tweaking a few ant properties. When your system needs to be deployed in multiple ways, you want to be able to change configurations rapidly without having to invest a lot in maintaining all of them. This is one of my favorite features of XDoclet.

XDoclet is my hammer, so I'm sure I'm seeing some things as nails that probably aren't. I do agree that with more dynamic systems, some of the calls for XDoclet go away. Personally, I welcome that. When XDoclet is burdoned generating dumb things that it shouldn't need to generate, then the module developers can focus on providing more complex code generation options than interfaces and deployment descriptors. I also agree that there ought to be a better way than hacking JavaDoc comments to express metadata. However, the current system provides some really unique benefits the shouldn't be overlooked.