JAR files included in the product

The full list of JAR files in the SaxonJ distribution is as follows. Here "12.#" means "12.0", "12.1", "12.2", etc. depending on the maintenance release.

JAR file	Size (approx)	Contents	Included in Editions
saxon-he-12.#.jar	5.5Mb	SaxonJ Home Edition. Contains all the software in SaxonJ-HE, except as noted below.	HE
saxon-pe-12.#.jar	6.3Mb	SaxonJ Professional Edition. Contains all the software in SaxonJ-PE, except as noted below.	PE
saxon-ee-12.#.jar	8Mb	SaxonJ Enterprise Edition. Contains all the software in SaxonJ-EE, except as noted below.	EE
saxon-he-xqj-12.#.jar	102Kb	Support for the XQJ (XQuery for Java) API. Provided as a separate JAR file in Saxon-HE so that it can be excluded from distributions that require pure OSI-approved open source licensing. The code is included as an integral part of SaxonJ-PE and SaxonJ-EE, so no separate JAR file is required in those cases.	HE
saxon-sql-12.#.jar	77Kb	Supports XSLT and XPath extensions for accessing and updating a relational database from within a stylesheet or query. Provided with SaxonJ-PE and SaxonJ-EE. The source code is open source so that it can be modified, but it requires support for element extensibility, which requires SaxonJ-PE or higher.	PE, EE
saxon-he-test-12.#.jar	132Kb	Test drivers for running the W3C test suites for XSLT and XQuery against SaxonJ-HE. The test drivers are published as open source code in the `saxon-resources` download. The test suites themselves are on GitHub: repositories `w3c/xslt30-test` and `w3c/qt3tests`.	HE
saxon-pe-test-12.#.jar	137Kb	Test drivers for running the W3C test suites for XSLT and XQuery against SaxonJ-PE. The test suites themselves are on GitHub: repositories `w3c/xslt30-test` and `w3c/qt3tests`.	PE
saxon-ee-test-12.#.jar	226Kb	Test drivers for running the W3C test suites for XSLT, XQuery, and XSD against SaxonJ-EE. The test suites themselves are on GitHub: repositories `w3c/xslt30-test`, `w3c/qt3tests`, `w3c/xsdtests`.	EE
icu4j-72.1.jar	11.9Mb	A copy of the open source ICU4J localization library, used to support sorting and date/number formatting in a wide variety of languages. If this JAR file is not present on the classpath, this will restrict the collations and localization options available to those that are found in the Java runtime. It should be possible to replace this JAR with a later version downloaded from the ICU project. (Previous SaxonJ releases used a tailored version of this JAR file. With experience, we found that this added complexity and delivered no tangible benefits.)	PE, EE
jline-2.14.6.jar	269Kb	JLine 2: an open source library supporting interactive command-line applications, including content completion and command history. This is used by the Gizmo utility.	HE, PE, EE
xmlresolver-4.6.0.jar	157Kb	XML Resolver: an open source library supporting the resolution of URIs using a catalog; it also handles the data and classpath URI schemes, and provides resource caching.	HE, PE, EE
xmlresolver-4.6.0-data.jar	1Mb	XML Resolver Data: a package of commonly used W3C resources, such as DTDs and external entities used by XHTML, SVG, and MathML; these will be automatically picked up by the XML Resolver avoiding a costly fetch from the W3C web site.	HE, PE, EE

When running any Java application, SaxonJ included, all Java classes that are needed must be present on the classpath. The classpath can be set in the form of an environment variable, or it can be included in the java command that invokes the application.

The manifest of the main Saxon JAR file (for example saxon-he-12.0.jar) includes a Class-Path entry that automatically brings in the jline and xmlresolver dependencies, so you should not normally need to add these to the classpath manually. In fact these dependencies are present in two forms: a versioned form (such as lib/jline-2.14.6.jar) which picks up the version that is issued with the Saxon product, and an unversioned form (lib/jline.jar) which is designed to make it easy to replace the issued version with a compatible maintenance release should this become necessary (see below).

The classpath is written as a list of filenames. These will either be the names of directories (folders) that contain relevant classes, or the names of JAR files containing the classes. On Windows, the names in the list are separated by semicolons; on Linux and macOS, a colon is used.

The table above lists the JAR files provided with SaxonJ that you may need to include on your classpath. In addition, you may need to include the following resource:

Resource	Description
saxon-license.lic	License file. This is needed only for running SaxonJ-EE/SaxonJ-PE. The license file is obtained when you purchase the product or when you apply for an evaluation license. If the license file is placed in the same directory as the `saxon-pe-12.#.jar` or `saxon-ee-12.#.jar` JAR file, then SaxonJ will usually be able to find it without further assistance; in some class-loading environments, however, the directory containing the license file (not the license file itself) needs to be listed on the classpath.

Resource

Description

saxon-license.lic

License file. This is needed only for running SaxonJ-EE/SaxonJ-PE. The license file is obtained when you purchase the product or when you apply for an evaluation license. If the license file is placed in the same directory as the saxon-pe-12.#.jar or saxon-ee-12.#.jar JAR file, then SaxonJ will usually be able to find it without further assistance; in some class-loading environments, however, the directory containing the license file (not the license file itself) needs to be listed on the classpath.

Updating third party libraries

It may happen from time to time that you want to upgrade to a more recent version of one of the third party libraries that’s bundled with Saxon. Exactly how to do this depends a little bit on your environment.

If you’re running in a build environment that uses Maven to resolve dependencies, point to the newer version of the relevant library. If necessary, configure your build system’s resolution strategy to favor the new version.
If you’re running with a classpath that you’ve configured, include the newer version of the library on the classpath before the Saxon jar file.
If you’re running the Saxon jar directly (with -jar or with only the Saxon library on the classpath), edit the contents of the lib directory where you installed Saxon.

Delete the library you wish to replace and copy the new version into that directory without its version number. For example, to replace the xmlresolver-4.2.0.jar APIs with a new version, perhaps xmlresolver-4.4.0.jar, delete xmlresolver-4.2.0.jar and copy the 4.4.0 jar file into the lib directory using the name xmlresolver.jar, without any version number.

Verifying the Saxon JAR files

Before releasing new versions of the SaxonJ JAR files, Saxonica signs them with a digital signature which you can use to verify that the files have not been tampered with. The signatures are based on a digital certificate issued to Saxonica by the security company GlobalSign.

You can verify that a particular JAR file (for example saxon-ee-12.0.jar) has a valid signature using the command:

jarsigner -verify saxon-ee-12.0.jar

More usefully, you can check that it was signed by Saxonica with the command:

jarsigner -verify -verbose saxon-ee-12.0.jar

This produces voluminous information about the contents of the JAR file, ending with details of the security certificate, something like this:

- Signed by "EMAILADDRESS=mike@saxonica.com, CN=Saxonica Limited, O=Saxonica Limited, L=Reading, ST=Berkshire, C=GB" Digest algorithm: SHA-256 Signature algorithm: SHA256withRSA, 4096-bit key Timestamped by "CN=GlobalSign TSA for Advanced - G4 - 003-01, O=GlobalSign nv-sa, C=BE" on Sat Jan 29 08:59:55 UTC 2022 Timestamp digest algorithm: SHA-256 Timestamp signature algorithm: SHA256withSHA256withRSA, 3072-bit key

The details will vary from release to release, but will always identify Saxonica as the originator, and give the date on which the JAR file was built prior to release.

Saxonica signs both the open-source and commercial JAR files. The signature does not prevent the JAR file being unpacked and modified, but it means that you can always distinguish a modified JAR file from the original.