Isn't that a problem for the ErrorListener, not the compiler?

In other words, if you re-use the same ErrorListener with multiple compilers in multiple threads, then you need to ensure your ErrorListener is thread safe.


On Thu, Dec 27, 2012 at 9:20 AM, Michael Sokolov <> wrote:
The Saxon documentation (javadoc) describes the compilers in the s9api
(XsltCompiler, XQueryCompiler, XPathCompiler) as thread-safe, but I'm
concerned that the error reporting mechanism (ErrorListener) cannot be
thread-safe since the ErrorListener is stored as state in the compiler,
and thus shared across threads.

Various other methods exist that allow changing the compiler's internal
state, and the documentation does say callers should not modify anything
after an initial construction. For the most part its state does seem as
if it could reasonably be shared across threads, so I suppose that
following that admonition one remains on solid ground, but I think that
for the ErrorListener this is not feasible, since errors resulting from
concurrent compilations will be intermingled.

Is there a way to invoke the compiler from multiple threads with error
reporting routed to the calling thread, or is it necessary to allocate a
compiler per-thread?

-Mike Sokolov

Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS,
MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current
with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft
MVPs and experts. ON SALE this month only -- learn more at:
saxon-help mailing list archived at

Archie L. Cobbs