Tuesday, January 20, 2015

JAXP: How to Retrieve Its Specification and Implementation Versions

In [1], we have discussed Package objects in Java are used to track a package's version information.  In this article, we will use JAXP 1.3 to demonstrate how version information is stored and retrieved.

JAXP


The Java API for XML Processing (JAXP) enables applications to parse, transform, validate and query XML documents using an API that is independent of a particular XML processor implementation. JAXP provides a pluggability layer to enable vendors to provide their own implementations without introducing dependencies in application code. Using this software, application and tool developers can build fully-functional XML-enabled Java applications for e-commerce, application integration, and web publishing.

The latest JAXP released with Java SE 8 is JAXP 1.6.[2]  It provides the capability of validating and parsing XML documents. The three basic parsing interfaces are:
In addition to the parsing interfaces, the API provides an XSLT interface to provide data and structural transformations on an XML document.

Instead of using the lastest JAXP 1.6, we have chosen an older version 1.3 for demonstration.  But, the principles remain the same (see [2] for JAXP 1.6 changes).

Specification and Implementation Version Information


In JAXP 1.3, specification version information is made available via the following java.lang.Package methods:
  • public String getSpecificationTitle()
    • Returns the title of the specification that this package implements. null is returned if it is not known.
  • public String getSpecificationVersion()
    • Returns the version number of the specification that this package implements. This version string must be a sequence of positive decimal integers separated by "."'s and may have leading zeros. 
    • When version strings are compared the most significant numbers are compared. null is returned if it is not known.
  • public String getSpecificationVendor()
    • Returns the name of the organization, vendor, or company that owns and maintains the specification of the classes that implement this package. null is returned if it is not known.
This version information is retrieved and made available by the ClassLoader instance that loaded the class(es). For example, a typical implementation will provide this information with the following values:
  • Specification-Title : Java API for XML Processing
  • Specification-Vendor : Sun Microsystems, Inc.
  • Specification-Version : 1.3
in the manifest (i.e., META-INF/MANIFEST.MF).

Implementation version information is also made available via the following java.lang.Package methods:
  • public String getImplementationTitle()
    • Returns the title of this implementation. null is returned if it is not known.
  • public String getImplementationVersion()
    • Returns the version of this implementation. It consists of any string assigned by the vendor of this implementation and does not have any particular syntax specified or expected by the Java runtime. 
    • It may be compared for equality with other package version strings used for this implementation by this vendor for this package. null is returned if it is not known.
  • public String getImplementationVendor()
    • Returns the name of the organization, vendor or company that provided this implementation.
This version information is retrieved and made available by the ClassLoader instance that loaded the class(es). For example, a typical implementation will provide this information with the following values:
Implementation-Title : Oracle XML Developer's Kit
Implementation-Vendor : Oracle USA, Inc.
Implementation-Version : 11.1.0.0.0

in the manifest (i.e., META-INF/MANIFEST.MF).

References

  1. Java Package: How to Retrieve Its Version Information
  2. JAXP 1.6 Enhancements in Java SE 8
    • JAXP 1.6 requires the use of the service provider loader facility defined by java.util.ServiceLoader to load services from service configuration files
      • The rationale for this is to allow for future modularization of the Java SE platform where service providers may be deployed by means other than JAR files and perhaps without the service configuration files. 
      • Note that the JAXP has always specified the use of the 'Services API' without reference to a specific API or service provider loading facility.
    • For more information see JEP 162: Prepare for Modularization as well as the JAXP 1.6 Change List.
  3. Project JAXP (Glassfish)



No comments: