<html><body>
<p>Elliotte wrote:<br>
&gt;&gt;&gt;The problem with this is that the unchecked factory can be used directly without a parser. The Builder should use it by default, but it should only be accessible to the Builder. i.e. it should be package protected, and should not require the user to set it. For more safety it should only be used if the parser is a known good parser, and not a custom XMLReader or XMLFilter. &lt;&lt;&lt;<br>
<br>
Well, this is typically what I'm looking for! There are some situations where you want to quickly build a JDOM without any SAXBuilder. Such a builder is not the only way to construct a tree.<br>
Let me give you 2 examples that we currently have a need such an optimization:<br>
1/ Generating java code that constructs a DOM. This is used to build a DOM from an HTML page<br>
2/ Reading an XMLS stream (see Denis web site) and construct a JDOM.<br>
<br>
This factory is really helping us having good performances (we currently ship with a custom build of JDOM!), and without this, the app will run really slower. That the reason why I reactivated the debate on this 2 weeks ago.<br>
<br>
I completly agree with Jason when he wrote:<br>
&gt;&gt;&gt;If you do choose to make use of the class, you know you're taking risk in exchange for speed.  In some business situations, this is a perfectly reasonable compromise to make.&lt;&lt;&lt;&lt;<br>
<br>
It's like when you're walking on a bridge. You have barriers to protected you from falling into the river. But if, for any reason, you want to jump over the barriers, it is at your own risks.<br>
<br>
PLEASE, do not make it private, as we really need it. Otherwise, we will still have to provide a custom build with all the deployment headaches of such a situation (WebSphere, JRun are bundled with JDOM...).<br>
<br>
Phil.<br>
</body></html>