The JAXB RI provides additional customizations that are not
defined by the JAXB specification. Note the following:
These features may only be used when the JAXB XJC
binding compiler is run in the -extension
mode.
All of the JAXB RI vendor extensions are defined in the
"http://java.sun.com/xml/ns/jaxb/xjc
"
namespace.
The namespaces containing extension binding declarations
are specified to a JAXB processor by the occurrence of the
global attribute @jaxb:extensionBindingPrefixes
within an instance of <xs:schema>
element.
The value of this attribute is a whitespace-separated list of
namespace prefixes. For more information, please refer to
section 6.1.1 of the JAXB Specification.
3.1.1. Index of Customizations
The JAXB RI supports the use of schema
component designator as a means of specifying the
customization target (of all standard JAXB customizations as well
as vendor extensions explained below.) To use this feature, use
the scd
attribute on <bindings> element instead
of the schemaLocation
and node
attributes.
Compared to the standard XPath based approach, SCD allows
more robust and concise way of identifying a target of a
customization. For more about SCD, refer to the scd example. Note
that SCD is a W3C working draft, and may change in the
future.
3.1.3. Extending a Common Super Class
The <xjc:superClass>
customization allows
you to specify the fully qualified name of the Java class that is
to be used as the super class of all the generated implementation
classes. The <xjc:superClass>
customization can
only occur within your <jaxb:globalBindings>
customization on the <xs:schema>
element:
In the sample above, the <xjc:superClass>
customization will cause all of the generated implementation
classes to extend the named class,
org.acme.RocketBooster
.
3.1.4. Extending a Common Super Interface
The <xjc:superInterface>
customization
allows you to specify the fully qualified name of the Java
interface that is to be used as the root interface of all the
generated interfaces. The <xjc:superInterface>
customization can only occur within your
<jaxb:globalBindings>
customization on the
<xs:schema>
element:
In the sample above, the
<xjc:superInterface>
customization will cause
all of the generated interfaces to extend the named interface,
org.acme.RocketBooster
.
3.1.5. Enhanced <jaxb:javaType>
The <xjc:javaType> customization can be used just like
the standard <jaxb:javaType> customization, except that it
allows you to specify an XmlAdapter
-derived
class, instead of parse&print method pair.
This customization can be used in all the places
<jaxb:javaType> is used, but nowhere else:
In the above example, LayerRate_T
simple type
is adapted by org.acme.foo.LayerRateAdapter
, which
extends from XmlAdapter
.
In the above example, all the use of
xsd:dateTime
type is adapter by
org.acme.foo.MyAdapterImpl
to
org.acme.foo.MyDateType
3.1.6. Experimental simpler & better binding mode
This experimental binding mode can be enabled as a part of
the global binding. See below:
When enabled, XJC produces Java source code that are more
concise and easier to use. Improvements include:
Some content model definitions, such as
A,B,A
, which used to cause an XJC compilation
error and required manual intervention, now compile out of
the box without any customization.
Some content model definitions that used to bind to
a non-intuitive Java class now binds to a much better Java
class:
When repetable elements are bound, the method name
will become plural.
Once again, readers are warned that this is an experimental binding mode, and therefore
the binding is subject to change in future versions of the JAXB RI
without notice. Please send feedbacks on this binding to
https://javaee.groups.io/g/metro
3.1.7. Alternative Derivation-by-restriction Binding Mode
Normally, the JAXB specification requires that a
derivation-by-restriction be mapped to an inheritance betwee n two
Java classes. This is necessary to preserve the type hierarchy,
but one of the downsides is that the derived class does not really
provide easy-to-use properties that reflect the restricted content
model.
This experimental <xjc:treatRestrictionLikeNewType>
changes this behavior by not preserving the type inheritance to
Java. Instead, it generates two unrelated Java classes, both with
proper properties. For example, given the following schema:
The generated Derived
class will look like this
(comment and annotations removed for brevity):
In contrast, without this customization the
Derived
class would look like the following:
3.1.8. Allow separate compilations to perform element
substitutions
In an attempt to make the generated code easier to use, the
JAXB specification sometimes choose bindings based on how certain
feature is used. One of them is element substitution feature. If
no actual element substitution happens in the schema, JAXB assumes
that the element is not used for substitution, and generates code
that assumes it.
Most of the time this is fine, but when you expect other
"extension" schemas to be compiled later on top of your base
schema, and if those extension schemas do element substitutions,
this binding causes a problem ( see
example.)
<xjc:substitutable> customization is a work around for
this issue. It explicitly tells XJC that a certain element is used
for element substitution head, even though no actual substitution
might be present in the current compilation. This customization
should be attached in the element declaration itself, like
this: