作者：
江南白衣
因为 Retrotranslator的出现， SpringSide 1.0终于放心升到JDK5.0，并保证仍然100%可以运行在JDK1.4的服务器上。
不能随意更改运行环境JDK的历史项目，客户真金白银买了不支持JDK5的Weblogic8.1的项目，一般只能看着JDK5的annotation、泛型和EJB3干咽口水，所以上帝說要有光，我们有了这个恩物。
和以前推荐的 Retroweaver一样，大家直接用JDK5开发，如果需要部署到JDK1.4的运行环境，就通过asm把Class转到JDK1.4的字节码。
但它不仅支持JDK5的语法，还支持JDK5的新增API。
下午试验了一下，把用了大量JDK5特征的EasyMock移植到JDK1.4，一行代码未改就通过了。正是由于这点，SpringSide终于下定决心升级，毕竟使用JDK5的框架越来越多，如果困守JDK1.4必然受到越来越多局限。既然现在有了完全兼容的保证，就升了吧。 本来这么一样东西应该是由Sun发行的，Java的开源社区强悍得吓人。
Retrotranslator的用法很简单，可以用命令行、Ant和IDEA插件自动转换， http://retrotranslator.sf.net 上讲得很清楚，可以转换Jar，也可以转换Class目录。
比较特别的是有个Verify选项，能确保你没有用到它暂时还不支持的JDK5 API（记得Classpath里要加入JDK1.4的rt.jar)。在 SpringSide的build.xml里已加入了这个verfiy target，确保代码仍然可以在JDK1.4上运行。（实践把springside部署回Tomcat5.0+JDK1.4环境，除了Spring cgilib式的AOP Proxy与泛型的反射函数有冲突外需进一步研究外，其它一切工作正常）
因为 Retrotranslator的出现， SpringSide 1.0终于放心升到JDK5.0，并保证仍然100%可以运行在JDK1.4的服务器上。
不能随意更改运行环境JDK的历史项目，客户真金白银买了不支持JDK5的Weblogic8.1的项目，一般只能看着JDK5的annotation、泛型和EJB3干咽口水，所以上帝說要有光，我们有了这个恩物。
和以前推荐的 Retroweaver一样，大家直接用JDK5开发，如果需要部署到JDK1.4的运行环境，就通过asm把Class转到JDK1.4的字节码。
但它不仅支持JDK5的语法，还支持JDK5的新增API。
下午试验了一下，把用了大量JDK5特征的EasyMock移植到JDK1.4，一行代码未改就通过了。正是由于这点，SpringSide终于下定决心升级，毕竟使用JDK5的框架越来越多，如果困守JDK1.4必然受到越来越多局限。既然现在有了完全兼容的保证，就升了吧。 本来这么一样东西应该是由Sun发行的，Java的开源社区强悍得吓人。
Retrotranslator的用法很简单，可以用命令行、Ant和IDEA插件自动转换， http://retrotranslator.sf.net 上讲得很清楚，可以转换Jar，也可以转换Class目录。
比较特别的是有个Verify选项，能确保你没有用到它暂时还不支持的JDK5 API（记得Classpath里要加入JDK1.4的rt.jar)。在 SpringSide的build.xml里已加入了这个verfiy target，确保代码仍然可以在JDK1.4上运行。（实践把springside部署回Tomcat5.0+JDK1.4环境，除了Spring cgilib式的AOP Proxy与泛型的反射函数有冲突外需进一步研究外，其它一切工作正常）
1418
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
