Details

    • Type: Bug Bug
    • Status: Resolved
    • Priority: Blocker Blocker
    • Resolution: Fixed
    • Affects Version/s: 1.3
    • Fix Version/s: None
    • Labels:
      None
    • Environment:

      windows oracle jvm 1.6_25

      Description

      Comparing a vaule to null using unequals (!=) yields false!

              Map<String, Integer> m = new HashMap<String, Integer>();
              m.put("a", 1);
              m.put("b", null);
              m.put("c", 1);
              JXPathContext c = JXPathContext.newContext(m);
              System.out.println(c.getValue("a != b") + " should be true");
              System.out.println(c.getValue("a != c") + " should be false");
              System.out.println(c.getValue("a = b") + " should be false");
              System.out.println(c.getValue("a = c") + " should be true");
              System.out.println(c.getValue("not(a = b)") + " should be true");
              System.out.println(c.getValue("not(a = c)") + " should be false");
      

      Output using 1.3:
      false should be true
      false should be false
      false should be false
      true should be true
      true should be true
      false should be false

      In 1.2 it works correctly!

        Activity

        Hide
        Matt Benson added a comment -

        Committed revision 1133499.

        Show
        Matt Benson added a comment - Committed revision 1133499.
        Hide
        Matt Benson added a comment - - edited

        Setting up a similar map to what you have described, and accessing via a bean property I still found the errors you describe. This issue was fairly difficult to triage, but my final diagnosis is that it is indicative of a bug. It is interesting to note that the value[@name='a'] != value[@name='b] approach succeeded, and of course the two approaches should yield equivalent results for any key conforming to QName restrictions. I would still consider it dangerous to depend on null values in JXPath, however. For example, if you add a mapping of "d":0 to your map, you will find that value[@name='d'] = value[@name='b'] because the fact that d refers to a numeric type forces the conversion of b's null value to a number, 0.0. XPath is tricky this way, and JXPath, dealing with types unknown to the XPath specification, only becomes trickier.

        Having said all that, and to return to the issue at hand, I found that certain existing JXPath tests assert that it should be possible to get a null value from the expression bean.nullProperty, but that iterating pointers from the expression bean.nullProperty[1] should yield no results. But this assigns a Java-centric meaning to XPath's [1] test, and it is my judgment that this is overstepping given that Javadoc for relevant methods states that non-Collection items should be treated as having length 1. Making the conscious decision to change an existing unit test is not a decision to make lightly, but in this case my opinion is that it is warranted.

        Show
        Matt Benson added a comment - - edited Setting up a similar map to what you have described, and accessing via a bean property I still found the errors you describe. This issue was fairly difficult to triage, but my final diagnosis is that it is indicative of a bug. It is interesting to note that the value[@name='a'] != value[@name='b] approach succeeded, and of course the two approaches should yield equivalent results for any key conforming to QName restrictions. I would still consider it dangerous to depend on null values in JXPath, however. For example, if you add a mapping of "d":0 to your map, you will find that value[@name='d'] = value[@name='b'] because the fact that d refers to a numeric type forces the conversion of b 's null value to a number, 0.0 . XPath is tricky this way, and JXPath, dealing with types unknown to the XPath specification, only becomes trickier. Having said all that, and to return to the issue at hand, I found that certain existing JXPath tests assert that it should be possible to get a null value from the expression bean.nullProperty , but that iterating pointers from the expression bean.nullProperty[1] should yield no results. But this assigns a Java-centric meaning to XPath's [1] test, and it is my judgment that this is overstepping given that Javadoc for relevant methods states that non-Collection items should be treated as having length 1. Making the conscious decision to change an existing unit test is not a decision to make lightly, but in this case my opinion is that it is warranted.
        Hide
        Matt Benson added a comment -

        Typically JXPath isn't expected to work with a Map/Object[]/Collection as its root context object, although I note your comment that this works in 1.2. Can you try adding your map to a simple object wrapper (e.g. org.apache.commons.lang.mutable.MutableObject) and report back the results of "value/a != value/b", and "value[@name='a'] != value[@name='b']" ?

        Show
        Matt Benson added a comment - Typically JXPath isn't expected to work with a Map / Object[] / Collection as its root context object, although I note your comment that this works in 1.2. Can you try adding your map to a simple object wrapper (e.g. org.apache.commons.lang.mutable.MutableObject ) and report back the results of "value/a != value/b" , and "value[@name='a'] != value[@name='b']" ?

          People

          • Assignee:
            Unassigned
            Reporter:
            Johannes Stelzer
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development