-
Bug
-
Resolution: Done
-
Major
-
None
-
None
EAP 7's EL equals operations work differently from EAP 6 one.
For example: put the following JSP in your web application (e.g. example.war)
<% request.setAttribute("testAttr", "01"); %> ${testAttr == 1}</br> ${param['foo'] == 1}<br> ${1 == param['foo']}<br> ${1 == (0+param['foo'])}<br>
Then, access the above JSP with curl command:
$ curl http://localhost:8080/example/test.jsp?foo=01
- Expected result (EAP 6's behavior):
true<br> true<br> true<br> true<br>
- Actual result (EAP 7's behavior):
false<br> false<br> false<br> true<br>
In the section 1.9.2 of EL 3.0 Specification, the ==,!= operators have the following step:
■If A==B, apply operator ■ If A is null or B is null return false for == or eq, true for != or ne. ■ If A or B is BigDecimal, coerce both A and B to BigDecimal and then: ■ If operator is == or eq, return A.equals(B) ■ If operator is != or ne, return !A.equals(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 then: ■ If operator is == or eq, return A.equals(B) ■ If operator is != or ne, return !A.equals(B) ■ If A or B is Byte, Short, Character, Integer, or Long coerce both A and B to Long, apply operator ■ If A or B is Boolean coerce both A and B to Boolean, apply operator ■ If A or B is an enum, coerce both A and B to enum, apply operator ■ If A or B is String coerce both A and B to String, compare lexically ■ Otherwise if an error occurs while calling A.equals(B), error ■ Otherwise, apply operator to result of A.equals(B)
Note that the step "If A or B is Byte, Short, Character, Integer, or Long coerce both A and B to Long, apply operator" should happen earlier than the step coercion to String. So, it appears that EAP 7's behavior violates the spec.
- clones
-
-
- Closed
-
-
-
- Closed
-
- is incorporated by
-
JBEAP-18346 [GSS](7.3.z) Upgrade jakarta.el from 3.0.2.redhat-00001 to 3.0.3.redhat-00002
-
- Closed
-
