[jdom-interest] Fast Factory

Dennis Sosnoski dms at sosnoski.com
Fri May 23 10:36:19 PDT 2003


Elliotte Rusty Harold wrote:

> 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. 

Ah, the "war on terrorism" as an API design criteria! Original, but not 
something I'd consider persuasive. Your hypothetical "malicious 
developers" have no need for any special API in order to create 
malformed documents - simple println calls are more than sufficient.

> 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. 

It's very broad-minded of you to be willing to accept that a sactioned 
parser may justify bypassing this. Of course, this change in attitude 
comes only after you've already implemented this in your own XOM API, 
with a claimed substantial speedup. It does seem a very lax approach, 
though. Why not make a list of the parsers you consider sufficiently 
compliant with the XML recommendation? That way you could check in the 
code at runtime to see if one of those parser is being used, and only 
turn off the checks if the parser is on your approved list? Better yet, 
just refuse to work with any parser not on the approved list. Of course, 
then you open up the issue of malicious substitution of sabotaged parser 
code. :-)

I have a hard time understanding the emotional weight this issue 
apparently carries for you. I'm not suggesting removing verification 
from JDOM, but only making it optional where practical. That would give 
developers the freedom to turn it off if they want, at the risk of 
shooting themselves in the foot. That's a tradeoff that most APIs 
provide and that Java developers generally seem to like.

  - Dennis




More information about the jdom-interest mailing list