JSP comparison operator behaviour

天涯浪子 提交于 2019-12-05 04:17:31
Not a bug

Behavior of == is not changed but behavior of {expr} is changed...

About versions :

In backward compatibility section of JSP Specification,

If the version specified is less than 2.1, then the {expr} syntax is simply processed as a String literal.

So, till EL 2.0 all will be treated as a string literal and compared with .equals as == will be converted to equals internally (Reference here), but in 2.1 It will not be converted to string and will throw exception saying that javax.el.ELException: Cannot convert No of type class java.lang.String to class java.lang.Long

About Comparision :

In JSP specification JSP.2.3.5.7 of EL version 2.1, following is specified...

  1. If A is null or B is null return false for == or eq, true for != or ne

  2. If A or B is Byte, Short, Character, Integer, or Long coerce both A and B to Long, apply operator

so, In first case,

${1 =="" } // ans is false as second one is null as per 1st rule.

and In second case,

${1 =="4" } // ans is false as both are different after coercing to Long as per 2nd rule.

Both will be coerced to long in above case with internal type conversion.

But not in the third case, ${1 =="Yes" } where second one is string can not be converted (coerced) to Long and java.el.ELException will be thrown with message "Cannot convert No of type class java.lang.String to class java.lang.Long".

As of JSP 2.1, the JSP uses the unified expression language (unified EL), which represents a union of the expression language offered by JSP 2.0 and the expression language created for JavaServer Faces technology.

It is very likely that the behaviour can be a bit different.

See section 1.18 of the JavaServer Pages 2.1 Expression Language Specification (available from here) for the complete type conversion rules.

标签
易学教程内所有资源均来自网络或用户发布的内容,如有违反法律规定的内容欢迎反馈
该文章没有解决你所遇到的问题?点击提问,说说你的问题,让更多的人一起探讨吧!