Bradley S. Huffman
hip at cs.okstate.edu
Sat Feb 28 12:06:06 PST 2004
Jason Hunter writes:
> Elliotte Rusty Harold wrote:
> > At 6:30 PM -0800 2/27/04, Jason Hunter wrote:
> >> FYI, I just made an interesting commit. People not on the commits
> >> list might want to take a look:
> >> http://lists.denveronline.net/lists/jdom-commits/2004-February/001745.html
> >> This change also made me think, should JDOMFactory really be an
> >> interface, a class, or an abstract class? The problem with an
> >> interface is that if we add methods after 1.0 it breaks everyone
> >> implementing the interface. With a class or abstract class, we can
> >> add w/o breakage so long as the new methods can have a standard
> >> implementation.
> > 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.
> I had a feeling you might point that out, Rusty. :-) And I'd agree
> with you if the design were such that you could easily get yourself into
> trouble. But you can't. You have to try really hard and use an awkward
> API in a class named "unchecked". (Note I explicitly avoided calling it
> a "fast builder" but rather chose "unchecked builder").
> 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.
I'm agree with Elliotte in that it would be nice to have it hidden,
unfortunately Java's package system doesn't allow it.
More information about the jdom-interest