Seeking class hierarchy advice

[Steve W. Jackson]

We have a critical class in our app which extends the DocumentImpl class
from an older Xerces-J implementation. I'm looking at what changes are
required to switch from 1.4.2 to 1.5, while at the same time hoping to
lose our dependence on the old versions of both Xerces and Xalan we're
currently using in favor of the built-in JAXP 1.3 in Java 1.5.

Making this class implement the Document interface isn't really
feasible, for obvious reasons. I could set the compile classpath to
include rt.jar and then make the class extend the Xerces DocumentImpl
buried deep inside there, but I'd prefer to avoid such things if
reasonably possible. So I'm looking for suggestions.

This class needs to be able to satisfy the "is a" test against the
org.w3c.dom.Document interface. But so far I'm not seeing anything
become clear in my mind as to how best to accomplish this without
requiring a great deal of code change. If that much effort is to be
required, it will mean waiting until after our pending new release to
get it done. Getting it done now would be better, and allow us to
lighten the load by removing some jar files no longer required.

TIA for any suggestions or ideas.

= Steve =

 

[Chris Uppal]

This class needs to be able to satisfy the "is a" test against the
org.w3c.dom.Document interface. But so far I'm not seeing anything
become clear in my mind as to how best to accomplish this without
requiring a great deal of code change.

It might help if you could explain why you think there might be a middle
position available at all.

I know nothing about your code, and only a little about Xerces, but it seems to
me that either your stuff is only weakly coupled to the current superclass (in
which case you could fairly easily switch to implementing Document via
delegation to an enclosed instance of Document), or that it makes real use the
DocumentImp stuff (in which case you are strongly coupled to that
/implementation/, and I can't see any reason to expect to be able to remove
that dependency without a complete re-write, duplicating much of what you
currently inherit). If there is a middle ground between these extremes, then
it must be because of something specific to how your current code works, which
you may know, but we don't (yet).

-- chris