Ranting against xdoclet
January 7th, 2004 by Hen[Continuing on from a linux user group on Java meeting today]
My negative to xdoclet is that it creates a cryptic system. I agree with
Dave, that it makes it harder for someone new to, say Struts, to learn
Struts if all the bits have been xdoclet’d, but my complaint is far more
central:
Let’s take a tag library as an example. Our Tag is in:
[ignore illegal package name]
package org.jug-l.example;
import *;
/**
* @jsp:tag name=”ifTomorrow”
*/
public class IfTomorrowTag extends TagSupport {
….
}
and somewhere in our JSP we have:
….
As a new coder to the JUG-L system, I am tasked with fixing a bug with the
tomorrow code. I find the jsp and start to delve. I find that the
ifTomorrow tag and decide it sounds like a suspect. My next step is
to…erm…well…that’s it. How do I see where the code is?
find . -type ‘*.java’ | xargs grep ‘ifTomorrow’
is all very well and good, but most Java coders are not savvy with the
command line. They can do a search in Windows, but that’s a pretty slow
way to work, relying on the gui search stuff to slowly pump things back.
That might be the personal opinion of a command-line fan.
If I am coding for myself, it would be easy to find. I would be working in
project FUTURE, so the code would be in:
org.jug-l.future.taglib
though it’s possible it might also be in org.jug-l.taglibs.future, because
I might be managing things differently. And it will be in a class called
IfTomorrowTag. What luck.
However, once you throw a group of coders together, relying on naming
conventions is a very risky business.
Some of you may be suggesting that I could just look in the .tld file.
Sure. Once I unpack the war file, find it and look at it. It’s possible
that with a more basic, less automated build system, I might also have a
.tld sitting wherever xdoclet left it, but the more automated a build is
the better it is, so relying on a messy build system to save you isn’t too
good.
So that’s why I think xdoclet is a dangerous idea. It has the same problem
when used for Struts, for EJB and probably for most other uses.
It does however have big pluses. Code generation is a very good idea. I
like the ‘X’ part of xdoclet. It’s the doclet part that is bad. Generating
locals, remotes, etc with a good naming scheme [xdoclet lets you set the
name…baaad…though maybe you can default now, been 2 years since I used
xdoclet for ejb] is good. But unenforced naming conventions fall apart in
the face of multiple developers.
There is also one xdoclet bit I’m looking forward to using, if someone
ever codes it:
public class Person {
/**
* @read
* @write
*/
String name;
}
All that said, I can quite easily see myself using xdoclet for myself, but like perl, I’m wary of joining a team with varying habits/experience who indulge in such.