IT博客-dproc2003-随笔分类-javahttp://www.cnitblog.com/dproc2003/category/8516.htmlzh-cnFri, 30 Sep 2011 13:15:44 GMTFri, 30 Sep 2011 13:15:44 GMT60Retrotranslator让你用JDK1.5的特性写出的代码能在JVM1.4中运行http://www.cnitblog.com/dproc2003/archive/2009/12/02/62970.htmlRocRocWed, 02 Dec 2009 07:51:00 GMThttp://www.cnitblog.com/dproc2003/archive/2009/12/02/62970.htmlhttp://www.cnitblog.com/dproc2003/comments/62970.htmlhttp://www.cnitblog.com/dproc2003/archive/2009/12/02/62970.html#Feedback0http://www.cnitblog.com/dproc2003/comments/commentRss/62970.htmlhttp://www.cnitblog.com/dproc2003/services/trackbacks/62970.htmlPreferences->Ant-Runtime然后Add External JARSs…把retrotranslator-transformer-1.2.1-bundle.jar加进来。 3． 上面准备做好了，就要开始用 Retrotranslator来转换你的字节码了。转换部分的Ant Build的target像下面这么写： 01. 02. 03. 05. 08. 09. 10. 11. 12. 13. 14. 4． 注意到上面destdir和srcdir都写成了一样的，我是让转换后的类直接把原来的类覆盖了，你可已把destdir设置为别的目录。 5． 最后就是运行了，你需要事先把retrotranslator-runtime-1.1.1-bundle.jar和backport-util-concurrent-3.0.jar配置在你的classpath中，比如是WEB应用程序，把它们拷到WEB-INF\lib中就行了。 比如，你写的是一个企业应用程序或者WEB程序，你只需要在打EAR或WAR包之前作以上的转换就行了。 另外，对于在JSP中用了JDK1.5的特性，就稍稍有点麻烦了，先要用特定于应用服务器的JSP编译器编译好JSP文件，在用 Retrotranslator 转换生成的 JSP 对应的class文件。如果中途对JSP文件有改动，我们不仅要编译并转换JSP 对应的class文件，然后覆盖掉服务器上的那个JSP对应的class文件，还要覆盖服务器上的那个JSP文件。 通常我们都不会对JSP文件预编译的。 所以我们的口号是：尽量不在JSP文件中写JAVA代码，写了也不要用JDK1.5的新特性，即使有复杂的东西也可以交给自定义标签处理。 比如struts标签 1. …… 不管amount是Integer还是 int 都无妨 再比如 1. 2. 3. 不管myBeanList是否是用的泛型，都能够正确取出数据来。如果要求严格点在给

Roc 2009-12-02 15:51 发表评论
]]>明明白白Unsupported major.minor version 49.0的错误http://www.cnitblog.com/dproc2003/archive/2009/12/02/62969.htmlRocRocWed, 02 Dec 2009 07:46:00 GMThttp://www.cnitblog.com/dproc2003/archive/2009/12/02/62969.htmlhttp://www.cnitblog.com/dproc2003/comments/62969.htmlhttp://www.cnitblog.com/dproc2003/archive/2009/12/02/62969.html#Feedback0http://www.cnitblog.com/dproc2003/comments/commentRss/62969.htmlhttp://www.cnitblog.com/dproc2003/services/trackbacks/62969.html 如果是在开发中，可以肯定的是现在真正算得上是 JAVA IDE 对于工程也都有编译选项设置目标代码的。例如 Eclipse 的项目属性中的 Java Compiler 设置，如图 自已设定编译选项，你会看到选择不同的 compiler compliance level 是，Generated class files compatibility 和 Source compatibility 也在变，你也可以手动调整那两项，手动设置后你就不用很在乎用的什么版本的编译器了，只要求他生成我们希望的字节码就行了，再引申一下就是即使源代码是用 VB 写的，只要能编译成 JVM 能执行的字节码都不打紧。在其他的 IDE 也能找到相应的设置对话框的。 其他时候，你一定要知道当前的 JVM 是什么版本，能接受的字节码主版本号是多少（可对照前面那个表）。获息当前 JVM 版本有两种途径： 第一：如果你是直接用 java 命令在控制台执行程序，可以用 java -version 查看当前的 JVM 版本，然后确定能接受的 class 文件版本 第二：如果是在容器中执行，而不能明确知道会使用哪个 JVM，那么可以在容器中执行的程序中加入代码　System.getProperty("java.runtime.version"); 或 System.getProperty("java.class.version")，获得 JVM 版本和能接受的 class 的版本号。 最后一绝招，如果你不想针对低版本的 JVM 用 target 参数重新编译所有代码；如果你仍然想继续在代码中用新的 API 的话；更有甚者，你还用了 JDK 1.5 的新特性，譬如泛型、自动拆装箱、枚举等的话，那你用 -target 1.4 -source 1.4 就没法编译通过，不得不重新整理代码。那么告诉你最后一招，不需要再从源代码着手，直接转换你所正常编译出的字节码，继续享用那些新的特性，新的 API，那就是：请参考之前的一篇日志：Retrotranslator让你用JDK1.5的特性写出的代码能在JVM1.4中运行，我就是这么用的，做好测试就不会有问题的。 七：再议一个实际发生的相关问题 这是一个因为拷贝 Tomcat 而产生的 Unsupported major.minor version 49.0 错误。情景是：我本地安装的是 JDK 1.5，然后在网上找了一个 EXE 的 Tomcat 安装文件安装了并且可用。后来同事要一个 Tomcat，不想下载或安装，于是根据我以往的经验是把我的 Tomcat 整个目录拷给他应该就行了，结果是拿到他那里浏览 jsp 文件都出现 Unsupported major.minor version 49.0 错误，可以确定的是他安装的是 1.4 的 JDK，但我还是有些纳闷，先前对这个问题还颇有信心的我傻眼了。惯性思维是编译好的 class 文件拿到低版本的 JVM 会出现如是异常，可现并没有用已 JDK 1.5 编译好的类要执行啊。 后来仔细看异常信息，终于发现了 %TOMCAT_HOME%\common\lib\tools.jar 这一眉目，因为 jsp 文件需要依赖它来编译，打来这个 tools.jar 中的一个 class 文件来看看，49.0，很快我就明白原来这个文件是在我的机器上安装 Tomcat 时由 Tomcat 安装程序从 %JDK1.5%\lib 目录拷到 Tomcat 的 lib 目录去的，造成在同事机器上编译 JSP 时是 1.4 的 JVM 配搭着 49.0 的 tools.jar，那能不出错，于是找来 1.4 JDK 的 tools.jar 替换了 Tomcat 的就 OK 啦。 八：小结 其实理解 major.minor 就像是我们可以这么想像，同样是微软件的程序，32 位的应用程序不能拿到 16 位系统中执行那样。 如果我们发布前了解到目标 JVM 版本，知道怎么从 java class 文件中看出 major.minor 版本来，就不用等到服务器报出异常才着手去解决，也就能预知到可能发生的问题。 其他时候遇到这个问题应具体解决，总之问题的根由是低版本的 JVM 无法加载高版本的 class 文件造成的，找到高版本的 class 文件处理一下就行了。

Roc 2009-12-02 15:46 发表评论
]]>