Details

Type: Bug

Status: Resolved

Priority: Major

Resolution: Fixed

Labels:None

Environment:
N/A
Description
In section 1.7.1 Binary Operators of the Expression Language Specification Version 3.0, there has been an additional Rule added that causes a Backwards compatibility issue.
From version 3.0 of the specification its states the following:
1.7.1 Binary operators  A {+,,*} B
■ If the operator is a +, and either A or B is a String, then + is a string concatenation < This is the newly added Rule.
operator.
■ If A and B are null, return (Long)0
■ If A or B is a BigDecimal, coerce both to BigDecimal and then:
■ If operator is +, return A.add(B)
■ If operator is , return A.subtract(B)
■ If operator is *, return A.multiply(B)
■ If A or B is a Float, Double, or String containing ., e, or E: < This Rule never gets reached now !!!!!
■ If A or B is BigInteger, coerce both A and B to BigDecimal and apply
operator.
■ Otherwise, coerce both A and B to Double and apply operator
■ If A or B is BigInteger, coerce both to BigInteger and then:
■ If operator is +, return A.add(B)
■ If operator is , return A.subtract(B)
■ If operator is *, return A.multiply(B)
■ Otherwise coerce both A and B to Long and apply operator
■ If operator results in exception, error
The problem with the newly added rule at the top of the order is that they " If A or B is a Float, Double, or String containing ., e, or E:" Never gets a chance to be parsed. This breaks backwards compatibility.