[jdom-interest] JDOM JSR

philip.nelson at omniresources.com philip.nelson at omniresources.com
Thu May 17 06:41:42 PDT 2001


> I would really like to know the design decisions for JDOM and their
> reasons. Its just because its seems to be contrary to all I 
> have learned
> and have experienced. 

That statement implies that the only way to do it is with interfaces and
factories??

> (Initially I asked for pointers to the 
> discussion
> and suggested an entry in the FAQ. Later I found some similar 
> questions
> and suggestions.)

These decisions were made a long time ago and *very* publically.  There was
certainly dissent and a follow up discussion led to dom4j.  The whole thing
is available in the list archives.

> 
> I am just starting a new project and have to choose the tools/APIs. My
> current impression is, I should give dom4j a first try, because I
> understand their design decisions.

If you can't live without factories and interfaces, you probably won't be
happy with JDOM.  Myself, I appreciate every day being able to say

Element el = new Element("name");

Later today I will send out the updated version of Ken Rune Hellend's
JDOMFactory code which will allow you to say:

	//override toString for debugging
	class superElement extends Element  {
		public String toString() {
			return "a subclass" + super.toString();
		}
	}
		
		
	SAXBuilder builder = new SAXBuilder();
      //use an inner class to override the element factory with my
SuperElement
	builder.setFactory(new DefaultJDOMFactory()  {
		public Element element(String name) {
			return new superElement(name);
		}
	});
	
	Document doc =  builder.build(new FileReader("afile.xml"));

Viola, easy subclassing.  This still doesn't make JDOM the perfect, most
flexible api.  While experimenting with decorators, I would have liked an
interface for each of the base JDOM types so I wouldn't have had an orphaned
super class.  However, in a year+ of using JDOM myself, and about the same
time answering questions for users, those use cases have been rare.  On the
daily basis the concrete classes are exactly what I want.  You will have
subclassing, decorating, implementation of new interfaces, ability to add a
vistor, all available to you easily.  To me this is a good compromise.




More information about the jdom-interest mailing list