<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2655.35">
<TITLE>RE: [jdom-interest] Fast Factory</TITLE>
</HEAD>
<BODY>
<P><FONT SIZE=2>Fast Verifier ....</FONT>
</P>
<P><FONT SIZE=2>Throwing $0.02 in on this discussion, I have had a look around the Verifier thing (spent a week looking in to performance improvements in JDOM).</FONT></P>
<P><FONT SIZE=2>Some notes on the issues I discovered:</FONT>
<BR><FONT SIZE=2>1. The Factory that creates JDOM objects is not in the same package as the JDOM objects themselves. This is a "headache" for making changes.</FONT></P>
<P><FONT SIZE=2>2. The Verifier is called from all over the place in the JDOM objects. Methods that are called at Factory time are for the most part indistinguishable from other contexts.</FONT></P>
<P><FONT SIZE=2>3. Verifier methods are "final", and thus (may) have compile time optimisations.</FONT>
<BR><FONT SIZE=2>4. Checking to see whether Verification should be called is potentially as slow as doing the verification itself.</FONT>
<BR><FONT SIZE=2>5. JDOM is designed to allow for Easy/Secure java MANIPULATION of XML documents (where validation is essential). It's purpose is not primarily to provide high-performance API during a third-party PARSING routine.</FONT></P>
<P><FONT SIZE=2>6. I tried using a "Fast Factory" approach, and I found that in reality (without making radical structural changes to the JDOM API), that the performance improvements were marginal.</FONT></P>
<P><FONT SIZE=2>So, my recommendation is that if you want a fast factory, try it. If it works, then tell us how it's done.</FONT>
</P>
<P><FONT SIZE=2>Having a "generic" debate about the merits/demerits of a given standard is really just academic, but if you can say that having a Fast Factory will save 50% of build time from SAX Parsers, then there will be a lot more conviction on why it should be an optional "switch".</FONT></P>
<P><FONT SIZE=2>So, your comment: "An API should provide a simple and easy way of working in the problem domain, without substantial performance penalties." The performance penalties with Verification in my experience are not substantial. Further, JDOM is very successful, nullifying your next statement: "If it </FONT></P>
<P><FONT SIZE=2>doesn't, developers will either bypass the API or use an alternative API".</FONT>
</P>
<BR>
<P><FONT SIZE=2>Rolf</FONT>
</P>
<BR>
<P><FONT SIZE=2>-----Original Message-----</FONT>
<BR><FONT SIZE=2>From: Dennis Sosnoski [<A HREF="mailto:dms@sosnoski.com">mailto:dms@sosnoski.com</A>]</FONT>
<BR><FONT SIZE=2>Sent: Saturday, May 24, 2003 2:37 PM</FONT>
<BR><FONT SIZE=2>To: Elliotte Rusty Harold</FONT>
<BR><FONT SIZE=2>Cc: Jason Hunter; Bradley S. Huffman; jdom-interest</FONT>
<BR><FONT SIZE=2>Subject: Re: [jdom-interest] Fast Factory</FONT>
</P>
<BR>
<P><FONT SIZE=2>Elliotte Rusty Harold wrote:</FONT>
</P>
<P><FONT SIZE=2>> At 10:36 AM -0700 5/23/03, Dennis Sosnoski wrote:</FONT>
<BR><FONT SIZE=2>></FONT>
<BR><FONT SIZE=2>>> I have a hard time understanding the emotional weight this issue </FONT>
<BR><FONT SIZE=2>>> apparently carries for you. I'm not suggesting removing verification </FONT>
<BR><FONT SIZE=2>>> from JDOM, but only making it optional where practical. That would </FONT>
<BR><FONT SIZE=2>>> give developers the freedom to turn it off if they want, at the risk </FONT>
<BR><FONT SIZE=2>>> of shooting themselves in the foot. That's a tradeoff that most APIs </FONT>
<BR><FONT SIZE=2>>> provide and that Java developers generally seem to like.</FONT>
<BR><FONT SIZE=2>></FONT>
<BR><FONT SIZE=2>></FONT>
<BR><FONT SIZE=2>> The whole point of an API is to keep developers from shooting </FONT>
<BR><FONT SIZE=2>> themselves in the foot. A developer uses an API because the API </FONT>
<BR><FONT SIZE=2>> designer knows more about the problem domain than the client </FONT>
<BR><FONT SIZE=2>> programmer does.</FONT>
</P>
<P><FONT SIZE=2>There's often some degree of specialized knowledge embedded in an API, </FONT>
<BR><FONT SIZE=2>but I'd argue that the primary purpose of an API is normally </FONT>
<BR><FONT SIZE=2>convenience. An API should provide a simple and easy way of working in </FONT>
<BR><FONT SIZE=2>the problem domain, without substantial performance penalties. If it </FONT>
<BR><FONT SIZE=2>doesn't, developers will either bypass the API or use an alternative API.</FONT>
</P>
<P><FONT SIZE=2>> I'm glad the java.net APIs remove from me the responsibility of </FONT>
<BR><FONT SIZE=2>> knowing every last detail of IP packet formats. I can rely on the API </FONT>
<BR><FONT SIZE=2>> to do the work for me. Similarly in XML we must not assume the client </FONT>
<BR><FONT SIZE=2>> programmers know as much as we do.</FONT>
</P>
<P><FONT SIZE=2>Nor should you assume that the client programmers are idiots who don't </FONT>
<BR><FONT SIZE=2>know what they're doing. If you *do* make this assumption, you'll end up </FONT>
<BR><FONT SIZE=2>with an API that's only used by idiots who don't know what they're doing.</FONT>
</P>
<P><FONT SIZE=2>> They are looking to JDOM precisely so they don't have to know every </FONT>
<BR><FONT SIZE=2>> last detail of XML like which C0 characters they can and cannot use in </FONT>
<BR><FONT SIZE=2>> text nodes. </FONT>
</P>
<P><FONT SIZE=2>This is certainly one plausible goal for writing an XML API, that it </FONT>
<BR><FONT SIZE=2>allow only constructing well-formed XML documents. I assume it's a major </FONT>
<BR><FONT SIZE=2>goal of your XOM project. It's *not* one of the stated goals for the </FONT>
<BR><FONT SIZE=2>JDOM project, AFAIKS.</FONT>
</P>
<P><FONT SIZE=2>> I have noticed that Java developers as a group tend to be relatively </FONT>
<BR><FONT SIZE=2>> uneducated about preconditions, postconditions, and class invariants </FONT>
<BR><FONT SIZE=2>> as opposed to, say, Eiffel or even C++ programmers. This probably has </FONT>
<BR><FONT SIZE=2>> to do with Java's lack of language level support for such features, a </FONT>
<BR><FONT SIZE=2>> lack of support that continues with the incredibly broken assertions </FONT>
<BR><FONT SIZE=2>> mechanism introduced in Java 1.4. However, the fact remains that class </FONT>
<BR><FONT SIZE=2>> invariants are at the core of data encapsulation, and are a critical </FONT>
<BR><FONT SIZE=2>> aspect of object oriented programming. Turning off class invariants is </FONT>
<BR><FONT SIZE=2>> at the same level as exposing fields as public, directly accessible </FONT>
<BR><FONT SIZE=2>> data. (Indeed the two practices go hand in hand.) Now maybe you don't </FONT>
<BR><FONT SIZE=2>> want to write object oriented programs, and that's OK; but if we are </FONT>
<BR><FONT SIZE=2>> going to design an object oriented API for an object oriented </FONT>
<BR><FONT SIZE=2>> language, then class invariants shouldn't be an issue, any more than </FONT>
<BR><FONT SIZE=2>> private fields. </FONT>
</P>
<P><FONT SIZE=2>The key choice in this is always how you choose the preconditions, </FONT>
<BR><FONT SIZE=2>postconditions, and class invariants. You're advocating that every </FONT>
<BR><FONT SIZE=2>character of data be verified, making verified data part of the class </FONT>
<BR><FONT SIZE=2>invariants - except for data coming from something that looks like a </FONT>
<BR><FONT SIZE=2>parser, which means it's *not* really a class invariant anymore. I'm </FONT>
<BR><FONT SIZE=2>suggesting there may be other cases where people also want to turn off </FONT>
<BR><FONT SIZE=2>the character verification in the interest of performance, and I think </FONT>
<BR><FONT SIZE=2>they should be able to do so.</FONT>
</P>
<P><FONT SIZE=2>Beyond that, I clearly favor APIs that provide flexibility while you </FONT>
<BR><FONT SIZE=2>favor APIs that enforce structure. This is a philosophical issue that </FONT>
<BR><FONT SIZE=2>I'd love to discuss with you over beer sometime, but not something that </FONT>
<BR><FONT SIZE=2>can ever be resolved on a general level.</FONT>
</P>
<P><FONT SIZE=2> - Dennis</FONT>
</P>
<P><FONT SIZE=2>_______________________________________________</FONT>
<BR><FONT SIZE=2>To control your jdom-interest membership:</FONT>
<BR><FONT SIZE=2><A HREF="http://lists.denveronline.net/mailman/options/jdom-interest/youraddr@yourhost.com" TARGET="_blank">http://lists.denveronline.net/mailman/options/jdom-interest/youraddr@yourhost.com</A></FONT>
</P>
</BODY>
</HTML>