Pluggability Layer
Designed to be flexible, JAXP allows you to use any XML-compliant processors from within your application. It does this with the factory APIs provided in jaxp-api.jar. High-level factory APIs will remain stable and are not subject to change. This jar contains:
- javax.xml.datatype
- javax.xml.namespace
- javax.xml.parsers
- javax.xml.stream
- javax.xml.transform
- javax.xml.validation
- javax.xml.xpath
These packages contain the factory APIs that give applications a consistent way to obtain instances of XML processing implementations. Each factory class is an abstract class that has a static newInstance() method that enables you to obtain a concrete instance of the abstract factory class. This static method uses an ordered lookup procedure to determine which concrete implementation of the abstract factory class to load.
This procedure applies to all factory classes. For example, xmlparserv2.jar in Oracle XDK for Java has the following factory types supported:[4]
- SAXParserFactory
- DocumentBuilderFactory
- TransformerFactory
- Use system property
- E.g. -Djavax.xml.parsers.SAXParserFactory=.
- Use the properties file "lib/jaxp.properties" in the JRE directory
- This configuration file is in standard java.util.Properties format and contains the fully qualified name of the implementation class with the key being the system property defined above.
- The jaxp.properties file is read only once by the JAXP implementation and it's values are then cached for future use. If the file does not exist when the first attempt is made to read from it, no further attempts are made to check for its existence. It is not possible to change the value of any property in jaxp.properties after it has been read for the first time.
- Use the Services API (as detailed in the JAR specification)
- The Services API will look for a classname in the file META-INF/services/javax.xml.parsers.SAXParserFactory in jars available to the runtime.
- Use Platform default SAXParserFactory instance.
Transition to Modularization
As described in [3], the project Jigsaw[9] was postponed to Java 9. This project is to design and implement a standard module system for the Java SE Platform and to apply that system to the Platform itself, and to the JDK.
To smooth the transition to Java 9, JAXP 1.6 bundled in Java SE 8 has adopted JEP 162[5] recommended changes—one of which requires the use of the service provider loader facility defined by java.util.ServiceLoader[6] 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.
3, Use the service-provider loading facilities
- Which is defined by the ServiceLoader class, to attempt to locate and load an implementation of the service using the default loading mechanism
- The service-provider loading facility will use the current thread's context class loader to attempt to load the service. If the context class loader is null, the system class loader will be used.
References
- SAXParserFactory (Java SE 7)
- SAXParserFactory (Java SE 8)
- There’s not a moment to lose! (Mark Reinhold)
- Getting Started with Oracle XML Developer's Kit for Java
- JEP 162: Prepare for Modularization
- java.util.ServiceLoader (since Java SE 6)
- JDK 1.6 and Xerces?
- JAXP 1.6 Enhancements in Java SE 8
- Project Jigsaw
- More new features coming to Java 9
- XML Catalog API (Implementation of OASIS Standard V1.1, 7 October 2005)
No comments:
Post a Comment