SAX2 RFD: Inheritance vs. Modification vs. Amalgamation

David Brownell david-b at
Wed May 19 23:11:17 BST 1999

David Megginson wrote:
> 1. Create a new interface, org.xml.sax.Parser2, that extends
>    org.xml.sax.Parser.
>    PRO: - provides nice, two-way compatibility
>         - easy to write adapters for existing SAX 1.0 drivers.
>    CON: - subclassing always leads to crime (see the GOF book for
>           copious warnings).

Actually, strike that "con" -- this isn't subclassing, it's
instead "subtyping", since Parser is an interface not a class.

Inheriting interfaces can't cause the crimes you'd get by relying
on parent class implementation artifacts!

My preference is clearly for #1 ... it's the standard way to
evolve existing interfaces in Java and most other interface
oriented frameworks.

> 2. Add the methods to org.xml.sax.Parser, and require applications to
>    catch NoSuchMethodException when using the new methods, in case
>    they're concerned about what version they're dealing with.

As Miles recently noted, this depends on everyone upgrading to
conform to the Java 2 standard.  (I recall the internal discussions
at the time.  This was a conscious change in behavior; JDK 1.1 and 1.0
are now viewed as being in error.)  While desirable, it's not a
thing I see happening very quickly ... particularly in embedded
systems which conform to the JDK 1.1 behavior!!

The motivation for changing this depended on ease of evolution in
the specific case where interface definers have strong control
over all implementations of the interface ... which clearly is
not the case with SAX!!  (Note that this change removes one of
the incentives to use abstract base classes inappropriately!)

> 3. Create a separate interface org.xml.sax.ParserProps (or something
>    like that), and require SAX2 drivers to implement both interfaces.

The primary difference between this and #1 is that this defines another
interface, and I don't see a benefit to that.

- Dave

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev at
Archived as: and on CD-ROM/ISBN 981-02-3594-1
To (un)subscribe, mailto:majordomo at the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo at the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa at

More information about the Xml-dev mailing list