Saxon

Further information on the history of this problem can be found here:

http://markmail.org/message/obgfqbnrkuhzl6wl

and here:

https://sourceforge.net/p/saxon/discussion/94027/thread/dda095cc

As stated on those threads, the problem originally arose because we wrote the services file to do what JDK 5 implemented, not what the JDK documentation said. It's probably time to move on now and do what the documentation says, leaving a problem only for those who are still using the old JDK.

Alternatively, I'm sorely tempted to abandon using the JAXP search mechanism entirely, at least for XPath. The utility of a mechanism that returns either an XPath 1.0 processor or an XPath 2.0 processor depending on what it happens to find on the classpath is highly questionable, and the JAXP XPath API is in any case so badly designed that we really don't want to encourage its use.

Thanks for the quick reply! Indeed, abandoning the dubious JAXP ServiceLoader search mechanism (i.e. removing META-INF/services/javax.xml.xpath.XPathFactory) would be an even better fix for our problem here. On the other hand if you'd consider this too big a change for a Saxon-HE-9.5.1-x maintenance release, then, in the interest of seeing a fix sooner rather than later, I'd vote for fixing the newlines in Saxon-HE-9.5.1-x.

We ran into problems with the ServiceLoader mechanism when we, in the same class loader, want to use saxon 9.5.* internally for XPATH 2. But also rely on a third party library that use XPath via JAXP and assumes via casts that the object model returned is for example a Node and not a TinyDocumentImpl. Resulting in a ClassCastException.

We discovered this problem when upgrading from Saxon 8.7 to 9.5.1-3. Both versions uses the ServiceLoader mechanism but we only ran into problems when using the later version. In our own code we are not relying on this mechanism. We instead specify object model, implementation class and class loader when calling XPathFactory.newInstance(). The third party code just uses the XPathFactory.newInstance() without arguments.

I haven't tried to modify the jar and remove the meta-inf/services folder. But i guess this might fix our problem. It however seems like a hack and will be hard to document and maintain in the long run.

Perhaps Saxon could be released in alternative versions for each release. One with the ServiceLoader mechanism and one without? I'm also very sceptic of the mechanism and would have no problem with it disappearing in a future release.

Regards,

Johan Mörén

Thanks for the comment. Yes, it's all too common for people to use the JAXP loading mechanism and then write code that relies on the behaviour of a particular implementation.

Michael Kay wrote:

I have updated the build scripts so that:

• In the next maintenance release of 9.5, we will use the correct JDK 1.6 format for these files, which means they will not work under JDK 1.5

• In Saxon 9.6, we will drop these files entirely, so the Saxon XPath processor will no longer be picked up by a JAXP factory search.

Great. Thanks!

Great news! Thanks!

I am using Saxon-PE 9.5.1.4. For some reason which I have not researched in detail my projects which run fine under Java 6 and Java 7 are hit by this problem under the newly arrived Java 8. Any news and ETA for the fix mentioned above?

We're expecting to produce a maintenance release containing this fix in the next few days.