The binding compiler can be launched using the appropriate
xjc shell script in the bin directory
for your platform. We also provide an Ant task to run the binding
complier - see the instructions for
the XJC Ant task.
% xjc -help
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.
-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
-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 : behave like XJC 2.0 and generate code that doesnt use any 2.1 features
-xmlschema : treat input as W3C XML Schema (default)
-relaxng : treat input as RELAX NG (experimental,unsupported)
-relaxng-compact : treat input as RELAX NG compact syntax (experimental,unsupported)
-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
-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
By default, the XJC binding compiler performs strict validation of the source schema
before processing it. Use this option to disable strict schema validation. This does not
mean that the binding compiler will not perform any validation, it simply means that it
will perform less-strict validation.
By default, the XJC binding compiler strictly enforces the rules outlined in the
Compatibility chapter of the JAXB Specification. Appendix E.2 defines a set of W3C XML
Schema features that are not completely supported by JAXB v1.0. In some cases, you may
be allowed to use them in the "-extension" mode enabled by this switch. In the default
(strict) mode, you are also limited to using only the binding customizations defined in
the specification. By using the "-extension" switch, you will be allowed to use the
JAXB Vendor Extensions
Specify one or more external binding files to process. (Each binding file must have
its own "-b" switch.) The syntax of the external binding files is extremely
flexible. You may have a single binding file that contains customizations for multiple
schemas or you can break the customizations into multiple bindings files:
xjc schema1.xsd schema2.xsd schema3.xsd -b bindings123.xjb
xjc schema1.xsd schema2.xsd schema3.xsd -b bindings1.xjb -b bindings2.xjb -b bindings3.xjb
In addition, the ordering of the schema files and binding files on the command line does
By default, the XJC binding compiler will generate the Java content classes in the
current directory. Use this option to specify an alternate output directory. The output
directory must already exist, the XJC binding compiler will not create it for you.
Specifying a target package via this command-line option overrides any binding
customization for package name and the default package name algorithm defined in the
Specify the HTTP/HTTPS proxy. The format is [user[:password]@]proxyHost[:proxyPort].
The old -host and -port are still supported by the RI for
backwards compatibility, but they have been deprecated. Note that the password
specified with this option is an argument that is visible to other users who use the
top command, for example. For greater security, use
Specify the HTTP/HTTPS proxy using a file. Same format as above, but the password
specified in the file is not visible to other users.
Specify where to find client application class files used by the
<jxb:javaType> and <xjc:superClass>
Specify catalog files to resolve external entity references. Supports TR9401,
XCatalog, and OASIS XML Catalog format. Please read the XML Entity and URI Resolvers
document or the catalog-resolver sample application.
By default, the XJC binding compiler does not write-protect the Java source files
it generates. Use this option to force the XJC binding compiler to mark the generated
Java sources read-only.
Supress the generation of package level annotations into **/package-info.java.
Using this switch causes the generated code to internalize those annotations into the
other generated classes.
Supress the generation of a file header comment that includes some note and timestamp. Using this makes the generated code more diff-friendly.
Avoid generating code that relies on any JAXB 2.1 features. This will allow the generated code to run with JAXB 2.0 runtime (such as JavaSE 6.)
Treat input schemas as W3C XML Schema (default). If you do not specify this switch,
your input schemas will be treated as W3C XML Schema.
Treat input schemas as RELAX NG (experimental, unsupported). Support for RELAX NG
schemas is provided as a JAXB Vendor Extension.
Treat input schemas as RELAX NG compact syntax(experimental, unsupported). Support
for RELAX NG schemas is provided as a JAXB Vendor Extension.
Treat input schemas as XML DTD (experimental, unsupported). Support for RELAX NG
schemas is provided as a JAXB Vendor Extension.
Treat input as WSDL and compile schemas inside it (experimental,unsupported).
Suppress compiler output, such as progress information and warnings.
Be extra verbose, such as printing informational messages or displaying stack traces
upon some errors.
Display a brief summary of the compiler switches.
Display the compiler version information.
Specify one or more schema files to compile. If you specify a directory, then xjc
will scan it for all schema files and compile them.
Non-Standard Command Line Options
Causes the generated code to expose SAX Locator information about the source XML in the Java bean instances after unmarshalling.
Causes all of the generated method signatures to include the synchronized keyword.
Mark the generated code with the annotation @javax.annotation.Generated.
Generate the specified episode file for separate compilation.
Deprecated and Removed Command Line Options
-host & -port
These options have been deprecated and replaced with the -httpproxy
option. For backwards compatibility, we will continue to support these options,
but they will no longer be documented and may be removed from future releases.
Since the JAXB 2.0 specification has defined a portable runtime, it is no
longer necessary for the JAXB RI to generate **/impl/runtime packages. Therefore,
this switch is obsolete and has been removed.
The -source compatibility switch was introduced in the first JAXB 2.0 Early
Access release. We have decided to remove this switch from future releases of JAXB
2.0. If you need to generate 1.0.x code, please use an installation of the 1.0.x
In general, it is safest to compile all related schemas as a single unit with
the same binding compiler switches.
Please keep the following list of restrictions in mind when running xjc. Most
of these issues only apply when compiling multiple schemas with multiple
invocations of xjc.
To compile multiple schemas at the same time, keep the following precedence
rules for the target Java package name in mind:
The "-p" command line option takes the highest precedence.
If targetNamespace is declared, apply targetNamespace
-> Java package name algorithm defined in the specification.
If no targetNamespace is declared, use a hardcoded package named
It is not legal to have more than one <jaxb:schemaBindings>
per namespace, so it is impossible to have two schemas in the same target namespace
compiled into different Java packages.
All schemas being compiled into the same Java package must be submitted to the
XJC binding compiler at the same time - they cannot be compiled independently and
work as expected.
Element substitution groups spread across multiple schema files must be compiled
at the same time.