UIMA
  1. UIMA
  2. UIMA-1839

String-subtype features can't be set to null?

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Minor Minor
    • Resolution: Fixed
    • Affects Version/s: 2.3
    • Fix Version/s: 2.3.1SDK
    • Component/s: Core Java Framework
    • Labels:
      None

      Description

      If you try to set a string-subtype feature to null, you get a NullPointerException:
      java.lang.NullPointerException
      at java.lang.String.compareTo(String.java:1167)
      at java.lang.String.compareTo(String.java:92)
      at java.util.Arrays.binarySearch0(Arrays.java:2001)
      at java.util.Arrays.binarySearch(Arrays.java:1943)
      at org.apache.uima.cas.impl.CASImpl.ll_setStringValue(CASImpl.java:3203)
      at org.apache.uima.cas.impl.FeatureStructureImpl.setStringValue(FeatureStructureImpl.java:130)

      The documentation doesn't specifically address whether this is allowed, but my intuition was that it should be. For one thing, a string-subtype feature can have the value null when it is uninitialized, so why shouldn't I be able to explicitly set it to null?

      A simple way to replicate is to add the line
      fs.setStringValue(stringSetFeat, null);
      to the test case method StringSubtypeTest.testCas()

        Activity

        Hide
        Marshall Schor added a comment -

        added test cases too, confirmed tests failed without fix, work with it.

        Show
        Marshall Schor added a comment - added test cases too, confirmed tests failed without fix, work with it.
        Hide
        Thilo Goetz added a comment -

        I think it's just a bug that should be fixed.

        Show
        Thilo Goetz added a comment - I think it's just a bug that should be fixed.
        Hide
        Marshall Schor added a comment -

        The purpose of a string subtype is to restrict the values to which a string can be set, to a pre-specfied (in the type) set of allowed values.

        I agree your example should not raise a null pointer exception.

        I wonder, though, if the "allowed values" should include some way to specify "null" as an allowed value?

        It's true that before the value is set, it has this value. So, it would sort of seem OK to allow setting it back to this value. But I guess one could argue that the whole point of the subtype is to specify restrictions on setting, and that therefore, having that functionality include prohibiting setting it "back" to null might be valuable.

        And, there is also the matter of specifying "null" as a special value, and not the string n-u-l-l, if we allowed this in the set of allowed values.

        I guess I feel this is a "corner case", and that no one has asked for "preventing" setting the value to null, so I'm ok with either approach.

        Show
        Marshall Schor added a comment - The purpose of a string subtype is to restrict the values to which a string can be set, to a pre-specfied (in the type) set of allowed values. I agree your example should not raise a null pointer exception. I wonder, though, if the "allowed values" should include some way to specify "null" as an allowed value? It's true that before the value is set, it has this value. So, it would sort of seem OK to allow setting it back to this value. But I guess one could argue that the whole point of the subtype is to specify restrictions on setting, and that therefore, having that functionality include prohibiting setting it "back" to null might be valuable. And, there is also the matter of specifying "null" as a special value, and not the string n-u-l-l, if we allowed this in the set of allowed values. I guess I feel this is a "corner case", and that no one has asked for "preventing" setting the value to null, so I'm ok with either approach.

          People

          • Assignee:
            Marshall Schor
            Reporter:
            Adam Lally
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development