Details

    • Type: Improvement Improvement
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 2.0 EA1
    • Fix Version/s: 2.1.13
    • Component/s: xjc
    • Labels:
      None
    • Environment:

      Operating System: All
      Platform: All

    • Issuezilla Id:
      131

      Description

      I'm not sure about the subcomponent; please re-assign if possible.

      JAXB 2.0 (used by XFire JAXB binding) generates getters for Boolean (wrapper
      type) with "is", rather than "get".

      AFAIK the JavaBeans spec only defines "is" for boolean, not Boolean.

        Issue Links

          Activity

          Hide
          kohsuke added a comment -

          This behavior is governed by the spec, and unfortunately it's just too late for
          the spec to change now.

          In terms of the user experience, thanks to auto-boxing, I don't think this will
          be a real issue for people. Is the problem that you are using Introspector and
          it's missing the property?

          Show
          kohsuke added a comment - This behavior is governed by the spec, and unfortunately it's just too late for the spec to change now. In terms of the user experience, thanks to auto-boxing, I don't think this will be a real issue for people. Is the problem that you are using Introspector and it's missing the property?
          Hide
          goonie added a comment -

          In this specific case, the object mapper "Dozer" misses the getter and needs to
          be configured with exception rules for each Boolean property.

          Each framework or application that deals with JavaBeans (POJOs) will fail. A
          very common case will be implementations of the javax.persistence API, like
          Hibernate.

          What's an early access good for, if there cannot be changes any more? This is a
          rather un-intrusive change, you could even allow for backwards compatibility if
          you fear that already existing implementations will fail.

          I don't understand your argument of auto-boxing. Method invocations are not
          auto-boxed (by Java5). Could you explain?

          Show
          goonie added a comment - In this specific case, the object mapper "Dozer" misses the getter and needs to be configured with exception rules for each Boolean property. Each framework or application that deals with JavaBeans (POJOs) will fail. A very common case will be implementations of the javax.persistence API, like Hibernate. What's an early access good for, if there cannot be changes any more? This is a rather un-intrusive change, you could even allow for backwards compatibility if you fear that already existing implementations will fail. I don't understand your argument of auto-boxing. Method invocations are not auto-boxed (by Java5). Could you explain?
          Hide
          kohsuke added a comment -

          Yes, early accesses are to solicit feedback, and we've been doing just that for
          the past year or more. But it's also true that we have to stop accepting
          feedback and ship at some point, or otherwise we can never ship anything. And
          unfortunately, that time is now.

          I don't know if you've seen this or not, but we just released the release
          candidate of the RI, and the spec has already or is shortly going to go for the
          final vote in JCP. So the kind of fixes we can make at this point for 2.0 is
          fairly limited, and this is clearly not one of them, since this is very much an
          intrusive change — any change that makes a difference in the generate
          signature is an intrusive change.

          I re-opened issue for 2.0.1 as an RFE to see if there's anything we can do. But
          the thing is, since the spec decides the signature that we generate, we can't
          really just "fix" this in the RI. There's a backward compatibility aspect, too
          — if we change the generated signature, it causes a trouble to a lot of people.

          But perhaps you (or someone) might be able to write a plugin to fix this, or we
          might be able to have a vendor-extension customization.

          The reason I mentioned auto-boxing is that you can write:

          boolean b = foo.isBar();

          even if isBar returns Boolean.

          Show
          kohsuke added a comment - Yes, early accesses are to solicit feedback, and we've been doing just that for the past year or more. But it's also true that we have to stop accepting feedback and ship at some point, or otherwise we can never ship anything. And unfortunately, that time is now. I don't know if you've seen this or not, but we just released the release candidate of the RI, and the spec has already or is shortly going to go for the final vote in JCP. So the kind of fixes we can make at this point for 2.0 is fairly limited, and this is clearly not one of them, since this is very much an intrusive change — any change that makes a difference in the generate signature is an intrusive change. I re-opened issue for 2.0.1 as an RFE to see if there's anything we can do. But the thing is, since the spec decides the signature that we generate, we can't really just "fix" this in the RI. There's a backward compatibility aspect, too — if we change the generated signature, it causes a trouble to a lot of people. But perhaps you (or someone) might be able to write a plugin to fix this, or we might be able to have a vendor-extension customization. The reason I mentioned auto-boxing is that you can write: boolean b = foo.isBar(); even if isBar returns Boolean.
          Hide
          kohsuke added a comment -
          Show
          kohsuke added a comment - Linking related topics: http://forums.java.net/jive/thread.jspa?threadID=15779
          Hide
          gturner added a comment -

          FYI for anyone stumbling upon this bug, here's a work-around. Pass your Schema
          through the following XSLT before XJC:

          <xsl:stylesheet xmlns="...target namespace here..."
          xmlns:xs="http://www.w3.org/2001/XMLSchema"
          xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
          xmlns:xalan="http://xml.apache.org/xalan"
          version="1.0"
          exclude-result-prefixes="xalan">
          <xsl:output indent="yes" xalan:indent-amount="2"/>

          <xsl:template match="/xs:schema">
          <xsl:copy>
          <xsl:apply-templates select="@*|node()"/>
          <xs:simpleType name="XBoolean">
          <xs:annotation>
          <xs:documentation>
          XBoolean exists only as a work-around to JAXB bugs
          https://jaxb.dev.java.net/issues/show_bug.cgi?id=555 and
          https://jaxb.dev.java.net/issues/show_bug.cgi?id=131.

          The use of this type declaration is slightly invalid, it exists to
          replace boolean, which may have lexical values "0" or "1" in
          addition to "true" or "false", this type is derived from NCName in
          order to get JAXB to generate an enum, NCName does not allow the
          values "0" or "1" (may not start with a digit).
          </xs:documentation>
          </xs:annotation>
          <xs:restriction base="xs:NCName">
          <xs:enumeration value="true"/>
          <xs:enumeration value="false"/>
          </xs:restriction>
          </xs:simpleType>
          </xsl:copy>
          </xsl:template>

          <xsl:template match="xs:attribute[@type='xs:boolean']/@type">
          <xsl:attribute name="type">XBoolean</xsl:attribute>
          </xsl:template>

          <xsl:template match="node()|@*">
          <xsl:copy>
          <xsl:apply-templates select="@*|node()"/>
          </xsl:copy>
          </xsl:template>
          </xsl:stylesheet>

          In my particular case (using Apache Commons BeanUtils) I had to create an
          additional Converter to marshal String to XBoolean, no big deal since I have
          already created Converters for Duration and XMLGregorianCalendar classes.

          Show
          gturner added a comment - FYI for anyone stumbling upon this bug, here's a work-around. Pass your Schema through the following XSLT before XJC: <xsl:stylesheet xmlns="...target namespace here..." xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsl="http://www.w3.org/1999/XSL/Transform" xmlns:xalan="http://xml.apache.org/xalan" version="1.0" exclude-result-prefixes="xalan"> <xsl:output indent="yes" xalan:indent-amount="2"/> <xsl:template match="/xs:schema"> <xsl:copy> <xsl:apply-templates select="@*|node()"/> <xs:simpleType name="XBoolean"> <xs:annotation> <xs:documentation> XBoolean exists only as a work-around to JAXB bugs https://jaxb.dev.java.net/issues/show_bug.cgi?id=555 and https://jaxb.dev.java.net/issues/show_bug.cgi?id=131 . The use of this type declaration is slightly invalid, it exists to replace boolean, which may have lexical values "0" or "1" in addition to "true" or "false", this type is derived from NCName in order to get JAXB to generate an enum, NCName does not allow the values "0" or "1" (may not start with a digit). </xs:documentation> </xs:annotation> <xs:restriction base="xs:NCName"> <xs:enumeration value="true"/> <xs:enumeration value="false"/> </xs:restriction> </xs:simpleType> </xsl:copy> </xsl:template> <xsl:template match="xs:attribute [@type='xs:boolean'] /@type"> <xsl:attribute name="type">XBoolean</xsl:attribute> </xsl:template> <xsl:template match="node()|@*"> <xsl:copy> <xsl:apply-templates select="@*|node()"/> </xsl:copy> </xsl:template> </xsl:stylesheet> In my particular case (using Apache Commons BeanUtils) I had to create an additional Converter to marshal String to XBoolean, no big deal since I have already created Converters for Duration and XMLGregorianCalendar classes.
          Hide
          Martin Grebac added a comment -

          This is already fixed for 2.2 (so that we don't break compatibility for 2.1.x line).

          Show
          Martin Grebac added a comment - This is already fixed for 2.2 (so that we don't break compatibility for 2.1.x line).
          Hide
          Martin Grebac added a comment -

          reopening to close with correct status

          Show
          Martin Grebac added a comment - reopening to close with correct status
          Hide
          Martin Grebac added a comment -

          We are not allowed to deliver the fix to 2.2 because of compatibility reasons.

          Show
          Martin Grebac added a comment - We are not allowed to deliver the fix to 2.2 because of compatibility reasons.
          Hide
          Martin Grebac added a comment -
              • Issue 679 has been marked as a duplicate of this issue. ***
          Show
          Martin Grebac added a comment - Issue 679 has been marked as a duplicate of this issue. ***
          Hide
          Martin Grebac added a comment -

          Added -enableIntrospection switch to XJC.

          Show
          Martin Grebac added a comment - Added -enableIntrospection switch to XJC.
          Hide
          Martin Grebac added a comment -

          Re-closing with proper status.

          Show
          Martin Grebac added a comment - Re-closing with proper status.

            People

            • Assignee:
              jaxb-issues
              Reporter:
              goonie
            • Votes:
              11 Vote for this issue
              Watchers:
              3 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: