This post originated from an RSS feed registered with Java Buzz by Norman Richards. Original Post: Liberating XDoclet from grunt code generation 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]

Although XDoclet can be used for quite a variety of code generation tasks, there is no denying the XDoclet's biggest niche has been doing the grunt code generation necessary to make the heavy EJB framework usable. That's been a noble call, but with EJB3 the need for most of what XDoclet does for EJB goes away.

What will become of XDoclet? It's quite hard to say. I'm mostly excited by the possibility of liberating XDoclet from the rather menial EJB tasks it does now and letting it move on to more interesting tasks. I think the most interesting EJB task is value object creation. That is one of the few tasks where XDoclet actually needs to apply some real domain knowledge to the task - change detection, data transfer to/from the bean, etc... If we didn't have to spend all our time generating all those interfaces and other silly things, then XDoclet could easily start doing more interesting things. Code generation is very powerful, but we only get a tiny glimpse of that with XDoclet. On the other hand, stripped of it's most compelling application, will XDoclet have the momentum to get to that point?

Of course, I'm not completely convinced that EJB3 really will eliminate all of XDoclet's EJB niche. You can't do away with deployment descriptors or deployment information without some nasty side effects. I'll comment on that another day though.