如何架构老版本JDK环境的系统

 

今天继续做机场的项目，开始架构系统首先要针对环境选择合适的开发包，由于早已多次确认生产环境下是websphere6.0而不是6.1，所以只能针对JDK1.4的版本之内选择开发包。这里解释一下，IBM的Websphere6.0只支持JDK1.4，到6.1以后才支持JDK5，当时火星人说了句很掉价的话：Websphere升级到6.1应该拿JDK5重新编译一下源码就可以了。强烈鄙视一下！要知道从JDK1.4升级到JDK5，不是所谓的那几个特性那么简单，整个J2EE的行业规范都从J2EE1.4升级到了J2EE5.0，作为全面支持J2EE规范的中间件Websphere来说，那意味着多少的工作量不言而喻，怎能一句重新编译那么简单！

 

话说回来，要针对JDK1.4选择开发包搭建环境本以为会很困难，SSH三大框架我最近的版本公布的时间大概都在2006年之后了，怎能确认它们能跑在JDK1.4的环境里呢？回忆起JVM的Class文件规范，在Class文件的Magic Number(前4个Byte之后)，紧跟着的就是编译时JDK的主次版本号(基本锁定在第8个字节作为判断依据)，哈哈，基于这种证据，我立即写了一个递归验证的小程序，依次把Spring2.5、Hibernate3.2和Struts2的JAR包解压之后校验里面有多少Class是基于JDK5编译的，结果如下：

l   Hibernate3.2全部基于JDK1.4编译，完全可以使用

l   Spring2.5大概有1/4基于JDK5编译，基本被我确认无法使用

l   Struts2也有大量的Class基于JDK5编译

 

虽然听说Struts2自带有JDK1.4重新编译的兼容包，但我本人并不太喜欢这种被迫的改动，所以就去找了找更早的版本Spring2.0，发现Spring2.0只有非常少量的类是用JDK5编译的，具体我就不列出是哪些了，比如TopLink相关的、HibernateAnnotation相关的等等。于是我干脆把这少部分的Class直接从JAR包中删除，然后重新打出新的JAR包来导入Project，一来确认所有能找到的Class都是JDK1.4编译的，未使用到JDK5的特性，二来也可以帮助我验证是否有任何删除的类被试图使用。Struts的话基本我就不再考虑去用Struts1.x了，直接使用Spring MVC加上Ajax已经足以满足系统功能。

 

接着我考虑到Ajax大量数据传递以前比较顺手的是DWR2.0，但检测之后发现有大量关键类是基于JDK5的，没办法我只能放弃DWR而采取别的方案，接着我想到以前曾用到的Json-lib也还不错，在Sourceforge上下到基于JDK1.3的，还有它依赖的那几个类common-collections、common-lang和ezmorph都检测了一边全部都是由JDK1.4编译的。

 

这下的检测持续了一会之后，基本上Lib库的挑选就完毕了，比较吃惊的是Log4j的检测结果所有类都基本是基于JDK1.1编译，让我非常感叹这帮开源框架的作者在开发的时候向前兼容考虑得太遥远了吧？还是他们就是在那个时代做出来一直用到现在的呢？至少我有印象的大量开始写Java的时候JDK1.4正逐渐的在被JDK5替代。

 

最后想说一下网上曾经也搜索过不少人讨论这种类似的问题，在JDK1.4的环境中JAR包的哪些版本可用，哪些不可用，很多人都再胡乱猜测，没有任何证据的就数这个能用，那个不能用；可见对Java的理解还不够透彻阿，Java Class最终是在被JVM以byte读入并解析使用的，当然基于JDK1.4的JVM解析Class使用的指令集和语法都只能使用JDK1.4编译下的产物啦，若JDK5编译的Class的byte被读入，自然会出现一些莫名其妙的错误，光问别人不如自己去校验一下Class的编译版本不就放心了么？

 

Over