Categories:
/ (391)(rss)
   general (23)(rss)
      austin (4)(rss)
      random (5)(rss)
      scooter (4)(rss)
   tech (368)(rss)
      books (38)(rss)
      coding (10)(rss)
      java (160)(rss)
      jobs (8)(rss)
      mac (67)(rss)
      misc (55)(rss)
      net (16)(rss)
      ruby (4)(rss)
      xml (7)(rss)

JBoss:
A Developer's Notebook
JBoss: A Developer's Notebook

JBoss 4.0:
The Official Guide
JBoss 4.0 Guide

XDoclet in Action
cover

Recent Entries

Search entries

Referers Disabled(referer spam)

NetNewsWire blogroll

CapMac
blosxom

       

Fri, 20 Feb 2004

::Is XDoclet really needed?:: [/tech/java] (10:07)

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 both 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 your 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 burdened 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.

4 comments

writebacks...

Dan Countryman wrote

code generation signals the need for refactoring
http://jroller.com/page/objectcountry/20040222#my_pet_peve_is_code

system log wrote

Is code generation neccessary?
A number of small blog entries has recently been asking this question specifically with XDoclet in mind, all started with this post by Javid Jamae and continued here and here .  My answer is very simple; yes, it is a necessary evil. It mig

Todd Blanchard wrote

Violates Blanchard's Law
Which basically says if you need to do code generation, then you're using the wrong tool for the job. XDoclet is useful because the Java language is bogged down with a lot of cumbersome static type information. Dynamically typed systems remove the need for most of that baggage. As an example - search the web for examples of NextStep Portable Distributed Objects (using dynamic proxies enabled by dynamic typing) vs CORBA (using code generation of proxies - one per class or interface).

Random Thoughts On Software wrote

Answering the "Is XDoclet Necessary" question
In an earlier blog entry, I pondered the question of whether or not XDoclet was a necessary tool. Norman Richards has a wonderful response to my question.

comment...

 
Name:
URL/Email: [http://... or mailto:you@wherever] (optional)
Title: (optional)
Comments:
Save my Name and URL/Email for next time