el 表达式 强制类型转换

今天有人问我了这个问题

jsp页面中，能否实现

<%  request.setAttrites("a","1234");  %>

a=${(a)+1}

 

 

我隐约记得是jsp会默认将a转化为integer类型然后相加的，但是记不太清楚了，于是专门写了这个jsp页面，进行了下验证。

发现确实是这个样子。

 

然后上网搜索了下，发现el表达式确实是将内容进行相应的值转换后然后返回相应的类型的。

 

相关帖子：

http://www.iteye.com/topic/177373

 

前段时间在工作中遇到了一个问题,在jsp页面通过JSTL判断对象是否等于'1',这个对象是char类型的,可是不管怎么操作,这个逻辑判断都是false,就算这个对象是字符'1',同样都是返回false.代码如下: 

Java代码  

1. <c:if test="${contract.c_attri_id=='1'}">经销</c:if>  

当时无法处理这个问题,于是一气之下将contract.c_attri_id对象的类型更改为String类型,该判断通过.当contract.c_attri_id为"1"时,那么以上代码将成功返回true,显示"经销". 
后来询问我过去的老师,最终知道了这个问题产生的真正原因: 
是这样的，EL和Java类型并不是一一对应的。 
这是所有解释语言的特点，数据类型都少，便于自动转型和提高开发效率，比如JavaScript。 
在你的这个情况下，contract.c_attri_id被转型为Long，想想java基础知识，char也可以表示整型数，对吧？ 
比如你的char型的'1'，就被转型成了long型的49，你可以打印${contract.c_attri_id}看看。 
等号右边的'1'，被认为是字符串，而不是char类型，EL自动做转型，依据是等号左边的类型。 
结果就是比较49==1。 
怎么解决呢？ 
我觉得你的解决方式是对的，就是转成String类型。 
java做业务开发的一个经验，针对JavaBean，就是尽量用对象类型，比如Long，String，Boolean。 
减少不必要的麻烦。 
性能上基本型是好，不过随着java5时代到来，你调用的API，比如Hibernate，对基本型都是包装为对等的对象的。 
这样频繁的装箱拆箱，性能就打很大折扣了。