Question

I found something pretty peculiar, and probably insignificant. When you define in an XSD an Element with the type xs:long, and you don’t set minOccurs="0", and you run it through JAXB, the resulting element is of type long. However, when you do set minOccurs="0" in the XSD element, the resulting element is of type Long. Notice the difference between the long and Long DataType

Now, with the work I do, I do some if (thisVariable == null) tests, and naturally, long cannot be null. Long can.

*What I would like to know, is this a bug in JAXB which causes this difference between the resulting variables, or is it intended for these resulting variables to come out the way they do? *

Here was the files I used to test with:

<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<xs:schema id="ReportRequestWrapper" xmlns="" xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:msdata="urn:schemas-microsoft-com:xml-msdata">
  <xs:element name="ReportRequestWrapper">
    <xs:complexType>
      <xs:sequence>
        <xs:element name="queryId" type="xs:long" minOccurs="0" />
        <xs:element name="reportId" type="xs:long" minOccurs="0" />
      </xs:sequence>
    </xs:complexType>
  </xs:element>
</xs:schema>

queryId and reportId came out as follows:

public class ReportRequestWrapper {

    protected Long queryId;
    protected Long reportId;

If I omitted the MinOccurs=”0″,

        <xs:element name="queryId" type="xs:long"  />
        <xs:element name="reportId" type="xs:long"  />

The result turned into

public class ReportRequestWrapper {

    protected long queryId;
    protected long reportId;

I just found this pretty curious and wanted some more information on this one.

Answer 1

No this is not a bug because when you say minOccurs = "0" which means that there is a possibility that queryId may be present or not.

So as you said long cannot be null, so the case that it is not present cannot be simulated without Long.

And when you don’t specify minOccurs = "0" this means that no matter what the value (other that null i.e. not present), queryId would be present. So this case is satisfied totally with long and does not require Long.