5.3 Overriding Names

Overriding the name of a class or of an element's child is something you may have to do to avoid name clashes. Usually it is more convenient to fix the XML schema, but you may not always be at liberty to do so.

Let's assume that you have a schema where a complex type has been given the uninspired name List:

<xsd:complexType name="List">
  <xsd:sequence>
    <xsd:element name="items" type="ItemType"
                 minOccurs="0" maxOccurs="unbounded"/>
  </xsd:sequence>
</xsd:complexType>

JAXB's schema compiler circumnavigates the threatening name clash between this class and java.util.List, required within the generated class code for declaring the field items. But wherever this class is used it is potentially in conflict with its namesake from java.util. To avoid having to use the full class name for one of these two classes, you might override the class name for the generated class:

<xsd:complexType name="List">
  <xsd:annotation>
    <xsd:appinfo>
      <jxb:class name="MyListType"/>
    </xsd:appinfo>
  </xsd:annotation>
  <xsd:sequence>
    <xsd:element name="items" type="ItemType"
                 minOccurs="0" maxOccurs="unbounded"/>
  </xsd:sequence>
</xsd:complexType>

Another unlucky choice for the name of an element or attribute would be Class. For this one, JAXB's workaround is the standard programmer's choice, i.e., it is replaced by Clazz. If you don't fancy this, you can request your own substitute, using an xjb:property element, like this:

<xsd:complexType name="School">
  <xsd:sequence>
    <xsd:element name="class" type="ClassType">
      <xsd:annotation>
        <xsd:appinfo>
          <jxb:property name="klass"/>
        </xsd:appinfo>
      </xsd:annotation>
    </xsd:element>
  </xsd:sequence>
</xsd:complexType>

Other Java keywords won't constitute a problem. The instance variable will be given a name consisting of an underscore followed by the letters of the keyword.

Yet another reason for changing a name arises from the use of the same name for a sub-element and an attribute within the same complex type definition. (Arguably this isn't good XML design. But, believe me, it does happen.)

<xsd:complexType name="ClassType">
  <xsd:sequence>
    <xsd:element name="grade" type="xsd:string" minOccurs="0"/>
  </xsd:sequence>
  <xsd:attribute name="grade" type="xsd:string" use="optional"/>
</xsd:complexType>

We'll resolve this conflict by renaming the attribute to gradeAttr, this time by specifying the property name in the bindings file.

<?xml version="1.0" encoding="UTF-8"?>
<jaxb:bindings xmlns:jxb="http://java.sun.com/xml/ns/jaxb"
               xmlns:xsd="http://www.w3.org/2001/XMLSchema"
               jxb:version="2.0">
  <jxb:bindings schemaLocation="School.xsd" node="/xsd:schema">
    <jxb:bindings node="//xsd:attribute[@name='grade']">
      <jxb:property name="gradeAttr"/>
    </jxb:bindings>
  </jxb:bindings>
</jxb:bindings>

XML Schema even lets you define a sequence where two individual elements have the same tag

<xsd:complexType name="StrangeType">
  <xsd:sequence>
    <xsd:element name="taga" type="xsd:string"/>
    <xsd:element name="tagb" type="xsd:string"/>
    <xsd:element name="taga" type="xsd:string"/>
  </xsd:sequence>
</xsd:complexType>

There is no such thing as a Java class that has two distinct fields with the same name. You must help the schema compiler to resolve this conflict, by renaming either element:

    ...
    <xsd:element name="taga" type="xsd:string">
      <xsd:annotation>
        <xsd:appinfo>
          <jxb:property name="taga2"/>
        </xsd:appinfo>
      </xsd:annotation>
    </xsd:element>
    ...

table of contents