[jira] [Issue Comment Edited] (JXPATH-151) null handling is inconsistent

["Matt Benson (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/JXPATH-151?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13046117#comment-13046117 ] 

Matt Benson edited comment on JXPATH-151 at 6/8/11 6:16 PM:
------------------------------------------------------------

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, although I would still consider it dangerous to depend on {{null}} values in JXPath.  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.

      was (Author: mbenson):
    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, although I would still consider it dangerous to depend on {{null}} values in JXPath.  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.
  
> null handling is inconsistent
> -----------------------------
>
>                 Key: JXPATH-151
>                 URL: https://issues.apache.org/jira/browse/JXPATH-151
>             Project: Commons JXPath
>          Issue Type: Bug
>    Affects Versions: 1.3
>         Environment: windows oracle jvm 1.6_25
>            Reporter: Johannes Stelzer
>            Priority: Blocker
>
> Comparing a vaule to null using unequals (\!=) yields false!
> {noformat}
>         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");
> {noformat} 
> Output using 1.3:
> {color:red} false should be true{color}
> 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!

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira