As per section 1.23 of the EL spec, the current ELResolver should be given an opportunity to apply custom type conversion before falling back on the standard rules. See also http://tomcat.markmail.org/thread/utk3nsn4aakjl4gj
Proposed fix: https://github.com/markt-asf/tomcat/commit/53e9f7b44e1cd450ab27025a0202dbf4d383851d https://github.com/markt-asf/tomcat/commit/d075c49460df3bcfbda3e6ed9f3e357003bad5df I plan to commit this to trunk and back-port to 8.0.x once svn returns to read-write.
This has been fixed in trunk and 8.0.x (for 8.0.16 onwards).
Reviewing r1643367 Reviewing ELSupport.compare(Object, Object) and coerceToNumber(ctx, Object, BigDecimal.class) calls there: 1. The first branch in compare() method: if (isBigDecimalOp(obj0, obj1)) { BigDecimal bd0 = (BigDecimal) coerceToNumber(ctx, obj0, BigDecimal.class); BigDecimal bd1 = (BigDecimal) coerceToNumber(ctx, obj1, BigDecimal.class); return bd0.compareTo(bd1); } In this branch isBigDecimalOp check returned true, so one of operands is already a BigDecimal. QUESTION: Does coerceToNumber() need to call ELResolver to convert it? Can it skip conversion if the object is already of the expected type. 2. Minor if (ctx.isPropertyResolved()) { return (Number) result; } It could be type.cast(result).