wood burning stoves 2.0*
The moose likes Web Component Certification (SCWCD/OCPJWCD) and the fly likes EL Relational Operators Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Android Security Essentials Live Lessons this week in the Android forum!
JavaRanch » Java Forums » Certification » Web Component Certification (SCWCD/OCPJWCD)
Bookmark "EL Relational Operators" Watch "EL Relational Operators" New topic
Author

EL Relational Operators

Narendra Dhande
Ranch Hand

Joined: Dec 04, 2004
Posts: 950
Hi,

I tested following EL Expressions



The output of the above is



The question is how the comparision is made on the boolean operands. From the above output it look like that they are corec to String and then compared lexically. If this is the case then how the expression at line 7 return true. Also in expressions 1,2,3 none of the operand is String. Is there is specific rules in EL.

${false eq 0} (0 without quotes giving me ELException )

Please Clarify.

Thanks


Narendra Dhande
SCJP 1.4,SCWCD 1.4, SCBCD 5.0, SCDJWS 5.0, SCEA 5.0
Christophe Verré
Sheriff

Joined: Nov 24, 2005
Posts: 14687
    
  16

== or eq will coerce both value to Boolean if one of them is Boolean.
So ${false eq "0"} will result in "0" being converted to a Boolean, whose value is false. Therefore, "false eq false" returns true.
The String coercion actually happens when neither of the values are Boolean.

The spec is very handy.
Check JSP.2.3.5.5 Relational Operators


[My Blog]
All roads lead to JavaRanch
Narendra Dhande
Ranch Hand

Joined: Dec 04, 2004
Posts: 950
Hi,

Thanks for the reply. I have gone through this specification, but I have little bit confusions while understanding the rules.

The spec also stated that if one of the operand is String, then both Corec to String. Which rule apply first.

In the line 1,2,3 both the operand of type Boolean constant. I think the Boolean does not comparable, then it should be error, if they are not corec to String.

In the following example, you can see that if either operand in numeric constant, then the numeric comparision is made, though the other operand is String. So, is there is any rule (precedence) when the value is corec to String or other type.



The output is



Please clarify

Thanks
Charles Lyons
Author
Ranch Hand

Joined: Mar 27, 2003
Posts: 836
The spec also stated that if one of the operand is String, then both Corec to String. Which rule apply first.

The rules should always be applied in the order they are given in the spec. So the equality test will perform these in order, executing whichever case it matches first:
  • A==B (reference comparison)
  • Null checks - returns false if either object is null
  • If either are BigDecimal, coerce to BD and A.equals(B)
  • If either are Float or Double, coerce both to Double and apply
  • BigInteger tests are next
  • Byte, Short... Long test are done here
  • If either are Boolean (or boolean primitives), coerce to Boolean and apply
  • If either are Strings, coerce both to String and compare lexically
  • ...

  • So:

    In the first we have two strings, so we'll compare lexically - and they obviously aren't equal. In the second we have two strings, and again we are testing lexically (although now for > and not for ==), and by the rules of String.compareTo(), we would expect "1" to be 'larger' than "01", as "1" would come after "01" in a dictionary. For line 17 however, one of the terms is a number - and by the list of rules above, numbers are done before strings... so convert "01" to the number 1 and do 1 > 1, which gets the answer false.

    In the following example, you can see that if either operand in numeric constant, then the numeric comparision is made, though the other operand is String. So, is there is any rule (precedence) when the value is corec to String or other type.

    This is what should happen, because, loosely speaking, numbers are done before strings. I think your second example shows this, but you didn't include the result for line 12, which I think should be true just like line 13. These lines are in fact equivalent, and are both converted to Integers before doing the comparison:


    I hope that helps.


    Charles Lyons (SCJP 1.4, April 2003; SCJP 5, Dec 2006; SCWCD 1.4b, April 2004)
    Author of OCEJWCD Study Companion for Oracle Exam 1Z0-899 (ISBN 0955160340 / Amazon Amazon UK )
    Christophe Verré
    Sheriff

    Joined: Nov 24, 2005
    Posts: 14687
        
      16

    Sorry Narendra, I was logged out.
    As Charles said, the order of coercion stated in the spec is important.
    For "==" or "eq" the Boolean coercion will be applied before the String one.
    Vidya Sethuraman
    Ranch Hand

    Joined: Sep 28, 2003
    Posts: 45
    Hi,

    I tried out the example
    1: ${true < false} <br>
    2: ${true == false } <br>
    3: ${true > false} <br>
    4: ${true > "false"} <br>
    5: ${false eq "false"} <br>
    6: ${false < "naren"} <br>
    7: ${false eq "0"} <br>
    but I'm getting the following error:
    javax.servlet.jsp.el.ELException: Attempt to apply operator "<" to arguments of type "java.lang.Boolean" and "java.lang.Boolean"

    Thanks!


    Vidya <br />(SCJP 1.4)
    Narendra Dhande
    Ranch Hand

    Joined: Dec 04, 2004
    Posts: 950
    Thanks Charles, Satou. Now it is clear.

    Thanks Vidya, I am expecting the output as is yours, as the boolean can not comparable. But I am getting the output like true or false. I am testing it on the Sun Java Application server 8.1. On which container you tested the above lines ?

    Thanks
    Christophe Verré
    Sheriff

    Joined: Nov 24, 2005
    Posts: 14687
        
      16

    No error in Tomcat 5.5 either. That's weird.
    Tomcat is using commons-el.jar to evalute the expressions but.... humm... strange.
    Narendra Dhande
    Ranch Hand

    Joined: Dec 04, 2004
    Posts: 950
    Hi,

    I also tested on Tomcat 5.5.7. No errors/exceptions

    Thanks
    Promod kumar
    Ranch Hand

    Joined: Jun 26, 2006
    Posts: 90
    true < false

    I am still not clear how it is evaluated. I pasted the section of the spec below. The above case is not covered by the spec. So this should be undefined per the spec. Am I right. When I try this on Tomcat I get false. Looks like true and false are converted to Strings and compared but the spec does not address this scenario. Let me know if I am missing anything. I don't think I have a good handle on this.

    Also I don't understand the first rule below. Can someone explain.

    JSP.2.3.5.6 A {<,>,<=,>=,lt,gt,le,ge} B
    � If A==B, if operator is <=, le, >=, or ge return true. Otherwise return false
    � If A is null or B is null, return false
    � If A or B is BigDecimal, coerce both A and B to BigDecimal and use the return
    value of A.compareTo( B ).
    � If A or B is Float or Double coerce both A and B to Double apply operator
    � If A or B is BigInteger, coerce both A and B to BigInteger and use the return
    value of A.compareTo( B ).
    � If A or B is Byte, Short, Character, Integer, or Long coerce both A and B to
    Long and apply operator
    � If A or B is String coerce both A and B to String, compare lexically
    � If A is Comparable, then:
    If A.compareTo (B) throws exception, error.
    Otherwise use result of A.compareTo(B)
    � If B is Comparable, then:
    If B.compareTo (A) throws exception, error.
    Otherwise use result of B.compareTo(A)
    � Otherwise, error
    Promod kumar
    Ranch Hand

    Joined: Jun 26, 2006
    Posts: 90
    Here is a good reference if you are banging your head against the wall about operators and corecion etc. I still don't have a reply for my earlier post.

    http://commons.apache.org/el/apidocs/org/apache/commons/el/Coercions.html
     
    I agree. Here's the link: http://aspose.com/file-tools
     
    subject: EL Relational Operators
     
    Similar Threads
    SoDuko puzzle
    Arithmetic value of "" in EL expressions
    EL problem
    EL's treatment of empty string
    scriptless jsp