JiBX
  1. JiBX
  2. JIBX-433

JiBX should not apply any default value unless an explicit default attribute is given

    Details

    • Type: Bug Bug
    • Status: Open Open
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: JiBX 1.2.3
    • Fix Version/s: None
    • Component/s: core
    • Labels:
      None
    • Number of attachments :
      0

      Description

      I have a JiBX mapping for a serial port that looks like this:

          <mapping abstract="true" class="com.exampleSerialConfig">
              <value name="baudRate" get-method="getBaudRate" set-method="setBaudRate" usage="optional"/>
              ...
           </mapping>
      

      The getBaudRate()/setBaudRate() methods take a value of type int.

      I would expect that if the XML contained no <baudRate> element, then setBaudRate() would not be invoked. The underlying Java class initializes this property to 9600, so I would expect that to be the default value if not specified.

      However, event when there's no <baudRate> element JiBX is invoking setBaudRate() with a value of zero.

      In other words, JiBX forcibly applies a (fixed: false, zero, or null) default value even when you specified that you didn't want a default value by not having any default="..." attribute.

      First of all, this is sub-optimal, because now there's no way now to have a non-zero/null default value that works the same way in both the Java and XML worlds, without specifying that default value in both your Java code and your JiBX XML files, which is both redundant and error-prone (because invariably you will change it in one place and forget to change it in the other).

      But even worse, this auto-application of default values actually serves absolutely no purpose, because the values it sets are the Java defaults anyway (false, zero, null, etc). Any newly-constructed object will already have those values; or if it doesn't, then they must have been changed in the constructor, which means the programmer wanted them to be different!

      So in summary this behavior is wrong for lots of reasons and actually accomplishes nothing. Please remove it.

        Activity

        There are no comments yet on this issue.

          People

          • Assignee:
            Unassigned
            Reporter:
            Archie Cobbs
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated: