Re: Re: LibxmlJ formalities

Nic Ferrier wrote:
> I'm aware of the issues. Even to get a decent mapping from java IO
> looked to be hard or crap (either frig the libxml2 source code so
> that it genuinely supports a modular IO API or just spit the stream
> into memory or a file - ugh).

No, that's an issue I tackled, or from what you say the Libxml guys
tackled meanwhile. LibxmlJ actually reads from InputStreams and
writes to OutputStreams transparently, no memory or file detour. At
least Libxml 2.5.3 supports this quiet nicely. If only everything
would have fitted that well!

> I hadn't realised there were thread issues. 

As it occurs to me after having read some old libxml mailing list
postings, Libxml wasn't designed to be multi-threaded in the
first place. Later on they fixed some issues and today claim that
Libxml is multi-threading capable.

However, there are Libxml callbacks (like the quiet important
LoadExternalEntity hook, which LibxmlJ connects to URIResolver)
that aren't provided with relevant context. Without context, you
cannot possibly use this functionality in a re-entrant way.

So Libxml may be capable of multi-threading as long as you only use
those callbacks that provide you with adequate context. But this
isn't enough for implementing the JAXP interface.

Because URIResolver is essential but the appropriate Libxml hook
doesn't provide context, I'm currently using an ugly workaround
involving global variables, which effectively is why LibxmlJ has a
single-thread bottleneck. This is the first issue I will talk about
with Daniel, I'll be happy to include you in the discussion.

>>On the bright side, and not surprisingly, gcj-compiled Java using
>>libxml/libxslt for XML processing is RAT fast and seems to exhibit
>>a low memory footprint compared to Xalan or other pure-Java
>>solutions.
> 
> This is why I'm interested in it. I think it's probably the right
> thing for a GNU java platform (where we don't necessarily care about
> portability).

FWIW, I strictly do care about portability. But I get your point,
it makes a difference whether you are bound to native code or not.

On the other hand, due to JAXP's plug-in nature this requirement
is quiet non-intrusive. Don't like it? Use something different.
Need for speed, don't like Apache-style licenses? Go through the
infinitely cruelsome hassles of... typing ./configure && make
(and, forget multithreading and working URIResolvers for now ;)

Julian