The problem with going to Java 1.6 is technical, which in a sense is a good thing (as long as I can get it sorted). We have a problem with ConcurrentModificationExceptions. We are getting these randomly (i.e. not reproducible) on 1.6 (and 1.5 I think), and not getting them in 1.4. Even worse, we can't reproduce it in our development environment, only when we do a full build of the product. From what I've read it sounds like the problem the exception refers to is probably happening in 1.4 as well but goes unreported, but at the moment we have a tested product which works in all our test cases on 1.4, so we have a level of confidence in it.

I have tried to get someone here to fix it a couple of times with no success. He thinks he knows what the problem is now but the fix involves changing a LOT of code, which is something we don't have the resource for at the moment. I'm hoping to get someone to look at it again early in the new year if I can get someone else on board so there's a chance we'll have sorted it by end of March, but I can't bet on that.

I'll try the suggestions from your other post tonight. I didn't realise the code I supplied was using dom. That's partly what I was meaning when I said the classes were quite confusing - I find it hard to tell if I'm using dom or TinyTree.

When I moved to s9api in Java 1.6, I managed to get the 493 transformations to run in 28 minutes when limited to 1.15gb ram. Our original code when set to 1.5gb would not actually run, and when we cut down the size of the input file until it did run, it was taking about 5 hours. I defiintely don't need convinced of the benefits of using TinyTree!

Cheers,
Kevin



From: "Michael Kay" <mike@saxonica.com>
To: "'Mailing list for the SAXON XSLT and XQuery processor'" <saxon-help@lists.sourceforge.net>
Date: 09/12/2008 18:42
Subject: Re: [saxon] Passing NodeSet parameter from Java





No, sorry, the s9api interface was designed to take advantage of Java 5.
 
I'd be interested to know what the "big problems" are. (Are they technical or political/commercial?) I'm currently intending to drop support for JDK 1.4 from Saxon 9.2 onwards, recognizing that this may leave a few users marooned on 9.1.
 
Michael Kay
http://www.saxonica.com/
 


From: Kevin Burges [mailto:KevinBurges@formedix.com]
Sent:
08 December 2008 02:56
To:
Mailing list for the SAXON XSLT and XQuery processor
Subject:
Re: [saxon] Passing NodeSet parameter from Java



I've just rewritten my code to use the s9api but when I went to run it i realised it seems to only work on java 5+. Unfortunately I'm stuck on 1.4.2 at the moment. I've been trying to move to 6, but there's big problems with that so it's not likely to happen for a few months. I don't suppose there's a version compiled against 1.4? I'm assuming not from what I can find, so it looks like I'll need revert back to the JAXP implementation tomorrow.


Cheers,
Kevin


From: "Michael Kay" <mike@saxonica.com>
To: "'Mailing list for the SAXON XSLT and XQuery processor'" <saxon-help@lists.sourceforge.net>
Date: 05/12/2008 08:47
Subject: Re: [saxon] Passing NodeSet parameter from Java






Transformer trans = factory.newTransformer(source) is just a shorthand for

 

is just a shorthand for

 

Templates templ = factory.newTemplates(source);

Transformer trans = templ.newTransformer();

 

I usually use the longer form, but it makes no difference unless you want to use the stylesheet more than once.

 

You're parsing and building the XML document here twice, which is very wasteful; it can't be a good idea to load two separate XPath engines either. Unfortunately the JAXP interfaces for doing this kind of thing aren't especially well coordinated, and unless you really need to keep yourself processor-independent, I would do it with s9api instead. It would then be:

 

Processor proc = new Processor();

DocumentBuilder builder = proc.newDocumentBuilder();

XdmNode doc = builder.build(xmlSource);

 

XsltCompiler xslt = proc.newXsltCompiler();

XsltExecutable exec = compiler.compile(xslSource);

 

XPathCompiler xpath = proc.newXPathCompiler();

 

for (...each instance...) {

   XPathSelector selector= xpath.compile(sElementPath).load();

   selector.setContextItem(doc);

   XdmValue nodes = selector.evaluate();

 

   XsltTransformer tr = exec.load();

   tr.setContextItem(doc);

   tr.setParameter(parameterName, nodes);

   tr.setDestination(....)

   tr.transform();

}

 

That's from memory, I might have got some of the names wrong, but it gives you the general flavour.

 

Michael Kay

http://www.saxonica.com/