head with a benchmark or two. Are there any realistic prototypes of the JSR proposal vs. your suggestion? I'm sure what you suggest is faster; I'm not sure how much.
Unfortunately, I don't have the source of the JSR-173 reference implementation. Even if I did, comparing two different parsers with a different API doesn't prove much. But we really don't need an implementation in order to make some comparisons.
The cursor API in the JSR can be used as a baseline because it doesn't create any objects and therefore doesn't have the overhead of the event API. But if the event API were changed to return singletons, it would be the same as the cursor API -- it would use as little memory as the cursor API but would have the added benefit of being layered nicely.
One glaring problem does jump out, though. Section 4.5.1, XMLInputFactory, describes yet another non-threadsafe parser configuration. It seems insane that an application can't control its own class loading in a threadsafe way. This one is even worse than the SAX API - _none_ of the ways to configure what gets loaded is threadsafe, nor is there any way for an application to disable any of them. Is it too late to fix this?
What do you mean when you say that it's even worse than SAX? Are you actually referring to the fact that parsers are not re-entrant? This doesn't present a problem for me because there is no meaning for a single parser instance to be parsing two documents at the same time.
P.S. Sorry about the reply-to confusion.
-- Andy Clark * [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
