Some of you will have already picked up from Twitter that Saxon 9.5 is now available. Or you may have seen that we've already had a bug reported on this list. It might sound odd, but that gives me great pleasure. The quality of Saxon owes so much to the users who do amazing things with it, and not only tell us when it doesn't work, but produce simple test cases that make the problems easy to fix. Having users who download the software on day 1 to test it is a great asset. So a big thank you to all our regular and loyal power users.
This is the first functionality release for almost 18 months, and you can be assured that this isn't because we've been spending our time on other things.
There's a large number of changes, all carefully documented. Some of them are relatively small things in response to user feedback, such as improving the diagnostics from the schema validator; some are continued implementation of the evolving W3C specs (XQuery 3.0 and XPath 3.0 are now essentially finished, and Saxon 9.5 is 100% conformant as far as we know - we pass every single one of the 23000 or so test cases). Some changes are more strategic, like the continued improvement in streaming capability for large documents, and new in this release, automatic support for parallel execution of stylesheets that have multiple input or multiple output documents.
The product is now pretty big (around 300K lines of code, I think), and I'm convinced that when you are managing such a large code base, you have to work hard on preventing structural decay. So there are internal changes that some of you will notice if you poke around the innards, for example the introduction of a new Sequence class to model all XPath values, replacing the old clumsy Value/ValueRepresentation split.
Bytecode generation which we introduced in 9.4 has held up pretty well. I was worried it might be a source of bugs and support hassle, but it has proved very reliable (well done O'Neil Delpratt, since this was largely his work). In this release, my two anxieties are probably the introduction of multi-threading for xsl:result-document (simply because multi-threading is so difficult to test thoroughly, and to debug if there are problems), and the introduction of a new regular expression engine. Both are indicators that we're not prepared to sit back on our laurels and take a low-risk "leave well alone" strategy.
Multithreading has always been part of the promise of using declarative languages, and it's increasingly important to take advantage of the fact that the hardware is now always multi-core. It's exciting to be finally delivering on this. Publishing workflows that generate hundreds or thousands of output documents from a single stylesheet will be the ones that benefit most.
As for the new regular expression engine (which is derived from Apache Jakarta), the existing approach which translated regular expressions from the XPath regex dialect to the Java regex dialect was getting increasingly cumbersome. Java hasn't moved forward in terms of Unicode support, and we wanted to be in more control of our destiny. The new regex engine is probably less code than the translator we were using before. I doubt it will deliver an immediate performance boost, but it does give us a lot more opportunity to introduce optimizations that take advantage of the way regular expressions are used in XSD and XPath.
I know there will be a few bugs in the first month or two, there always are; I know that although we are now running probably half a million tests before we release, it's not nearly enough. Those of you with mission-critical applications will probably want to hold back and exercise caution, and quite rightly so, because we know how dependent you are on the software's reliability. For those of you more keen to stay in front of the curve, please do try it out and give us your feedback, and as always we will do our very best to respond.
Oh, and finally: I'm interested in expanding the team. If you're interested and qualified, or know someone who is, then come and talk. We're based in Reading, UK, and I do think that co-location is important to create an effective team.