commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Matt Benson (JIRA)" <j...@apache.org>
Subject [jira] [Issue Comment Edited] (JXPATH-151) null handling is inconsistent
Date Wed, 08 Jun 2011 18:18:58 GMT

    [ 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:18 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, 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.

      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

Mime
View raw message