You are viewing a plain text version of this content. The canonical link for it is here.
Posted to j-dev@xerces.apache.org by ne...@ca.ibm.com on 2002/12/03 00:26:50 UTC

does anyone care about XMLEntityScanner?

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:  neilg@ca.ibm.com



---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-j-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-j-dev-help@xml.apache.org


Re: does anyone care about XMLEntityScanner?

Posted by Ted Leung <tw...@sauria.com>.
Can you say a little more about the performance boost?

Ted
----- Original Message -----
From: <ne...@ca.ibm.com>
To: <xe...@xml.apache.org>
Sent: Monday, December 02, 2002 3:26 PM
Subject: does anyone care about XMLEntityScanner?


> 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:  neilg@ca.ibm.com
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: xerces-j-dev-unsubscribe@xml.apache.org
> For additional commands, e-mail: xerces-j-dev-help@xml.apache.org
>



---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-j-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-j-dev-help@xml.apache.org


Re: does anyone care about XMLEntityScanner?

Posted by Andy Clark <an...@apache.org>.
neilg@ca.ibm.com wrote:
> 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

How is this done considering that the inner class
accesses fields and methods of the outer class? My
question is more in terms of design.

-- 
Andy Clark * andyc@apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-j-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-j-dev-help@xml.apache.org