[jdom-interest] Fast Factory

[Elliotte Rusty Harold]

At 9:03 PM -0700 5/22/03, Dennis Sosnoski wrote:

>Users of a library should be able to take off the training wheels 
>when they want to. Most users will probably leave them on anyway, 
>but insisting on keeping them welded in place is condescending to 
>your target developers.

Verification checks, i.e. preconditions and postconditions and class 
invariants, aren't training wheels. They are fundamental aspects of 
an API.  Removing the requirement for well-formedness is like 
removing the requirements to emit correct TCP/IP packets from a 
sockets API. Sure there are reasons why a programmer might want to 
emit bad TCP/IP data, but I'll be damned if my sockets API is going 
to help you write denial of service attacks.  Similarly, I see no 
reason for an XML API to allow malicious developers to pollute the 
XML space with malformed documents.

Of course, outright maliciousness is far less common than simple 
mistakes. However, the effects of a mistake can be equally 
devastating. That's why a good sockets API doesn't allow you to 
create malformed IP packets, and why a good XML API doesn't allow you 
to create malformed documents.

I am OK with not redoing the well-formedness checks if the parser is 
doing them. (I do wonder if perhaps we should check whether we've got 
a real parser in place rather than a hacked up XMLFilter) However, 
someone's got to do them.

I do strongly recommend that before any work takes place on this, you 
first carefully benchmark the actual Document building process to see 
where the bottlenecks are. Two people who did this in the last six 
months have reported on this list that turning off verification did 
not give them significant performance gains.  That's a little 
surprising. In XOM, I found that turning off verification did speed 
things up noticeably. However, possibly JDOM is currently stuck in 
some other hole like the flyweight pattern for namespaces that XOM 
doesn't share.  It's also possible that XOM's Verifier is more 
expensive than JDOM's. For instance, XOM's handles surrogates 
correctly which I don't think JDOM's yet does.
-- 

   Elliotte Rusty Harold
   elharo at metalab.unc.edu
   Processing XML with Java (Addison-Wesley, 2002)
   http://www.cafeconleche.org/books/xmljava
   http://www.amazon.com/exec/obidos/ISBN%3D0201771861/cafeaulaitA