As described in the post “APIs To Be Removed from Java 11,” a JAXB implementation is no longer included with JDK 11. In this post, I look at using the xjc compiler provided with the JAXB (Java Architecture for XML Binding) reference implementation in conjunction with OpenJDK 11 to compile XML schema files into Java classes.
Prior to Java SE 6, developers wanting to use JAXB with a Java SE application needed to acquire a JAXB implementation separately because one was not provided with the Java distribution. A JAXB implementation was included with Java starting with Java SE 6. This was convenient in many cases, but made things a bit more difficult when developers wished to use a newer version or different implementation of JAXB than the one provided with the JDK. When modularity was introduced with OpenJDK 9, the JAXB implementation was moved into the java.xml.bind module and was marked as deprecated for removal. The JAXB implementation was removed altogether with JDK 11. This post looks into using JAXB’s xjc compiler with OpenJDK 11.
Because JDK 11 no longer includes an implementation of JAXB, one must be acquired separately. For this post, I will be using version 2.3.0 of the JAXB reference implementation. The JDK version used in this post is JDK 11.0.2 General-Availability Release.
Running the xjc scripts without arguments leads to help/usage being rendered to standard output.
Usage: xjc [-options ...] <schema file/URL/dir/jar> ... [-b <bindinfo>] ...
If dir is specified, all schema files in it will be compiled.
If jar is specified, /META-INF/sun-jaxb.episode binding file will be compiled.
Options:
-nv : do not perform strict validation of the input schema(s)
-extension : allow vendor extensions - do not strictly follow the
Compatibility Rules and App E.2 from the JAXB Spec
-b <file/dir> : specify external bindings files (each <file> must have its own -b)
If a directory is given, **/*.xjb is searched
-d <dir> : generated files will go into this directory
-p <pkg> : specifies the target package
-m <name> : generate module-info.java with given Java module name
-httpproxy <proxy> : set HTTP/HTTPS proxy. Format is [user[:password]@]proxyHost:proxyPort
-httpproxyfile <f> : Works like -httpproxy but takes the argument in a file to protect password
-classpath <arg> : specify where to find user class files
-catalog <file> : specify catalog files to resolve external entity references
support TR9401, XCatalog, and OASIS XML Catalog format.
-readOnly : generated files will be in read-only mode
-npa : suppress generation of package level annotations (**/package-info.java)
-no-header : suppress generation of a file header with timestamp
-target (2.0|2.1) : behave like XJC 2.0 or 2.1 and generate code that doesnt use any 2.2 features.
-encoding <encoding> : specify character encoding for generated source files
-enableIntrospection : enable correct generation of Boolean getters/setters to enable Bean Introspection apis
-disableXmlSecurity : disables XML security features when parsing XML documents
-contentForWildcard : generates content property for types with multiple xs:any derived elements
-xmlschema : treat input as W3C XML Schema (default)
-dtd : treat input as XML DTD (experimental,unsupported)
-wsdl : treat input as WSDL and compile schemas inside it (experimental,unsupported)
-verbose : be extra verbose
-quiet : suppress compiler output
-help : display this help message
-version : display version information
-fullversion : display full version information
Extensions:
-Xinject-code : inject specified Java code fragments into the generated code
-Xlocator : enable source location support for generated code
-Xsync-methods : generate accessor methods with the 'synchronized' keyword
-mark-generated : mark the generated code as @javax.annotation.Generated
-episode <FILE> : generate the episode file for separate compilation
-Xpropertyaccessors : Use XmlAccessType PROPERTY instead of FIELD for generated classesThe xjc compiler scripts (bash file and DOS batch file) are conveniences for invoking the jaxb-xjc.jar. The scripts invoke it as an executable JAR (java -jar) as shown in the following excerpts:
- Windows version (
xjc.bat):%JAVA% %XJC_OPTS% -jar "%JAXB_HOME%\lib\jaxb-xjc.jar" %* - Linux version (
xjc.sh):exec "$JAVA" $XJC_OPTS -jar "$JAXB_HOME/lib/jaxb-xjc.jar" "$@"
As the script excerpts above show, an environmental variable XJC_OPTS is included in the invocation of the Java launcher. Unfortunately, the JAXB reference implementation JAR cannot be simply added to the classpath via -classpath because running excutable JARs with java -jar only respects the classpath designated within the executable JAR via the MANIFEST.MF‘s Class-Path (which entry exists in the jaxb-ri-2.3.0.jar as “Class-Path: jaxb-core.jar jaxb-impl.jar“).
One way to approach this is to modify the script to use the JAR as a regular JAR (without -jar) and explicitly execute the class XJCFacade, so that the classpath can be explicitly provided to the Java launcher. This is demonstrated for the Windows xjc.bat script:
%JAVA% -cp C:\lib\javax.activation-api-1.2.0.jar;C:\jaxb-ri-2.3.0\lib\jaxb-xjc.jar com.sun.tools.xjc.XJCFacade %*
In addition to the JAXB reference implementation JAR javax.activation-api-1.2.0.jar, I also needed to include the javax.activation-api-1.2.0.jar JAR on the classpath because the JavaBeans Application Framework (JAF) is a dependency that is also no longer delivered with the JDK (removed via same JEP 320 that removed JAXB).
It’s also possible, of course, to not use the XJC scripts at all and to run the Java launcher directly. The script ensures that environment variable JAXB_HOME is set. This environment variable should point to the directory into which the JAXB reference implementation was expanded.
With these changes, the JAXB xjc compiler can be executed against an XSD on the command line using JDK 11.
Published on Java Code Geeks with permission by Dustin Marx, partner at our JCG program. See the original article here: Running JAXB xjc Compiler with OpenJDK 11 Opinions expressed by Java Code Geeks contributors are their own. |
