Hi all, Elena's done some performance work that's showed, simply by concretizing org.apache.xerces.impl.XMLEntityScanner, we gain a bit of performance. For my own purposes in implementing XML 1.1 support, I've found it useful to take XMLEntityManager.EntityScanner--the only concrete implementation of XMLEntityScanner in our codebase--out of XMLEntityManager and make it a freestanding class. (This way I can extend it easily with an XML 1.1 entity scanner and leave the rest of the entity manager virtually unchanged). A rather obvious combination of these efforts would be simply to call the no-longer-inner-class implementation of XMLEntityScanner by the name XMLEntityScanner, thereby removing one layer of inheritance and entirely doing away with the abstract class.
Is there some reason why this wouldn't be a good idea? This would not involve changing any signatures, so shouldn't be backward incompatible; there aren't any concrete methods in XMLEntityScanner, so it's not at all obvious why any existing code would call any superclass methods... Thoughts? Neil Neil Graham XML Parser Development IBM Toronto Lab Phone: 905-413-3519, T/L 969-3519 E-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
