- 浏览: 1577642 次
- 性别:
- 来自: 厦门
文章分类
- 全部博客 (603)
- T_java (145)
- T_script&ASP (51)
- T_C/C++ (25)
- T_PowerBuilder (11)
- T_Database (53)
- T_odoo (7)
- T_应用服务器 (50)
- T_专_条形码 (6)
- T_专_负载均衡器 (4)
- T_操作系统 (94)
- T_信息安全 (41)
- T_专_搜索引擎 (14)
- T_L_PHP (58)
- T_L_Delphi (18)
- T_L_.NET、C#、VisualStudio (25)
- T_L_Objective-C (6)
- T_移动开发 (53)
- T_网络 (109)
- T_大数据 (2)
- T_嵌入式 (2)
- T_小众技术 (24)
- T_未分类 (58)
- L_旅游印记 (1)
- L_生活随笔 (48)
- L_中国文化 (18)
- L_户外与生存 (0)
最新评论
-
csbean4004:
不知道哪传来得恶习,发帖子不好好发,故意弄错一些东西,很讨厌
让HTML5支持后置摄像头 -
withthewind:
终于找到一个可以用的了。。。
如何用VBA取得Word文档中的标题前面的序号 -
busbby:
兄弟,无法下载,说文件不完整
一个好用的Outlook ost格式文件转pst文件的工具 -
yijavakevin:
密码啊~解压密码多少?
一个二维条形码组件 -
vipbooks:
你给的那个链接根本无法下载,跳到官网看了下最新版12M,但点下 ...
十步以内完成精细web打印
一:要解决的问题
我们在尝鲜 JDK1.5 的时候,相信不少人遇到过 Unsupported major.minor version 49.0 错误,当时定会茫然不知所措。因为刚开始那会儿,网上与此相关的中文资料还不多,现在好了,网上一找就知道是如何解决,大多会告诉你要使用 JDK 1.4 重新编译。那么至于为什么,那个 major.minor 究竟为何物呢?这就是本篇来讲的内容,以使未错而先知。
我觉得我是比较幸运的,因为在遇到那个错误之前已研读过《深入 Java 虚拟机》第二版,英文原书名为《Inside the Java Virtual Machine》( Second Edition),看时已知晓 major.minor 藏匿于何处,但没有切身体会,待到与 Unsupported major.minor version 49.0 真正会面试,正好是给我验证了一个事实。
首先我们要对 Unsupported major.minor version 49.0 建立的直接感觉是:JDK1.5 编译出来的类不能在 JVM 1.4 下运行,必须编译成 JVM 1.4 下能运行的类。(当然,也许你用的还是 JVM 1.3 或 JVM 1.2,那么就要编译成目标 JVM 能认可的类)。这也解决问题的方向。
二:major.minor 栖身于何处
何谓 major.minor,且又居身于何处呢?先感性认识并找到 major.minor 来。
写一个 Java Hello World! 代码,然后用 JDK 1.5 的编译器编译成,HelloWorld.java
用 JDK 1.5 的 javac -d . HelloWorld.java 编译出来的字节码 HelloWorld.class 用 UltraEdit 打开来的内容如图所示:
从上图中我们看出来了什么是 major.minor version 了,它相当于一个软件的主次版本号,只是在这里是标识的一个 Java Class 的主版本号和次版本号,同时我们看到 minor_version 为 0x0000,major_version 为 0x0031,转换为十制数分别为0 和 49,即 major.minor 就是 49.0 了。
三:何谓 major.minor 以及何用
Class 文件的第 5-8 字节为 minor_version 和 major_version。Java class 文件格式可能会加入新特性。class 文件格式一旦发生变化,版本号也会随之变化。对于 JVM 来说,版本号确定了特定的 class 文件格式,通常只有给定主版本号和一系列次版本号后,JVM 才能够读取 class 文件。如果 class 文件的版本号超出了 JVM 所能处理的有效范围,JVM 将不会处理该 class 文件。
在 Sun 的 JDK 1.0.2 发布版中,JVM 实现支持从 45.0 到 45.3 的 class 文件格式。在所有 JDK 1.1 发布版中的 JVM 都能够支持版本从 45.0 到 45.65535 的 class 文件格式。在 Sun 的 1.2 版本的 SDK 中,JVM 能够支持从版本 45.0 到46.0 的 class 文件格式。
1.0 或 1.2 版本的编译器能够产生版本号为 45.3 的 class 文件。在 Sun 的 1.2 版本 SDK 中,Javac 编译器默认产生版本号为 45.3 的 class 文件。但如果在 javac 命令行中指定了 -target 1.2 标志,1.2 版本的编译器将产生版本号为 46.0 的 class 文件。1.0 或 1.1 版本的 JVM 上不能运行使用-target 1.2 标志所产生的 class 文件。
JVM 实现的 第二版中修改了对 class 文件主版本号和次版本号的解释。对于第二版而言,class 文件的主版本号与 Java 平台主发布版的版本号保持一致(例如:在 Java 2 平台发布版上,主版本号从 45 升至 46),次版本号与特定主平台发布版的各个发布版相关。因此,尽管不同的 class 文件格式可以由不同的版本号表示,但版本号不一样并不代表 class 文件格式不同。版本号不同的原因可能只是因为 class 文件由不同发布版本的 java 平台产生,可能 class 文件的格式并没有改变。
上面三段节选自《深入 Java 虚拟机》,啰嗦一堆,JDK 1.2 开启了 Java 2 的时代,但那个年代仍然离我们很远,我们当中很多少直接跳在 JDK 1.4 上的,我也差不多,只是项目要求不得不在一段时间里委屈在 JDK 1.3 上。不过大致我们可以得到的信息就是每个版本的 JDK 编译器编译出的 class 文件中都带有一个版本号,不同的 JVM 能接受一个范围 class 版本号,超出范围则要出错。不过一般都是能向后兼容的,知道 Sun 在做 Solaris 的一句口号吗?保持对先前版本的 100% 二进制兼容性,这也是对客户的投资保护。
四:其他确定 class 的 major.minor version 办法
1)Eclipse 中查看
Eclipse 3.3 加入的新特征,当某个类没有关联到源代码,打开它会显示比较详细的类信息,当然还未到源码级别了,看下图是打开 2.0 spring.jar 中 ClasspathXmlApplicationContext.class 显示的信息
2)命令 javap -verbose
对于编译出的 class 文件用 javap -verbose 能显示出类的 major.minor 版本,见下图:
3) MANIFEST 文件
把 class 打成的 JAR 包中都会有文件 META-INF\MANIFEST,这个文件一般会有编译器的信息,下面列几个包的 META-INF\MANIFEST 文件内容大家看看
·Velocity-1.5.jar 的 META-INFO\MANIFEST 部份内容
Manifest-Version: 1.0
Ant-Version: Apache Ant 1.7.0
Created-By: Apache Ant
Package: org.apache.velocity
Build-Jdk: 1.4.2_08
Extension-Name: velocity
我们看到是用 ant 打包,构建用的JDK是 1.4.2_08,用 1.4 编译的类在 1.4 JVM 中当然能运行。如果那人用 1.5 的 JDK 来编译,然后用 JDK 1.4+ANT 来打包就太无聊了。
·2.0 spring.jar 的 META-INFO\MANIFEST 部份内容
Manifest-Version: 1.0
Ant-Version: Apache Ant 1.6.5
Created-By: 1.5.0_08-b03 (Sun Microsystems Inc.)
Implementation-Title: Spring Framework
这下要注意啦,它是用的 JDK 1.5 来编译的,那么它是否带了 -target 1.4 或 -target 1.3 来编译的呢?确实是的,可以查看类的二进制文件,这是最保险的。所在 spring-2.0.jar 也可以在 1.4 JVM 中加载执行。
·自已一个项目中用 ant 打的 jar 包的 META-INFO\MANIFEST
Manifest-Version: 1.0
Ant-Version: Apache Ant 1.7.0
Created-By: 1.4.2-b28 (Sun Microsystems Inc.)
用的是 JDK 1.4 构建打包的。
第一第二种办法能明确知道 major.minor version,而第三种方法应该也没问题,但是碰到变态构建就难说了,比如谁把那个 META-INFO\MANIFEST 打包后换了也未可知。直接查看类的二进制文件的方法可以万分保证,准确无误,就是工具篡改我也认了。
五:编译器比较及症节之所在
现在不妨从 JDK 1.1 到 JDK 1.7 编译器编译出的 class 的默认 minor.major version 吧。(又走到 Sun 的网站上翻腾出我从来都没用过的古董来)
JDK 编译器版本 | target 参数 | 十六进制 minor.major | 十进制 minor.major |
jdk1.1.8 | 不能带 target 参数 | 00 03 00 2D | 45.3 |
jdk1.2.2 | 不带(默认为 -target 1.1) | 00 03 00 2D | 45.3 |
jdk1.2.2 | -target 1.2 | 00 00 00 2E | 46.0 |
jdk1.3.1_19 | 不带(默认为 -target 1.1) | 00 03 00 2D | 45.3 |
jdk1.3.1_19 | -target 1.3 | 00 00 00 2F | 47.0 |
j2sdk1.4.2_10 | 不带(默认为 -target 1.2) | 00 00 00 2E | 46.0 |
j2sdk1.4.2_10 | -target 1.4 | 00 00 00 30 | 48.0 |
jdk1.5.0_11 | 不带(默认为 -target 1.5) | 00 00 00 31 | 49.0 |
jdk1.5.0_11 | -target 1.4 -source 1.4 | 00 00 00 30 | 48.0 |
jdk1.6.0_01 | 不带(默认为 -target 1.6) | 00 00 00 32 | 50.0 |
jdk1.6.0_01 | -target 1.5 | 00 00 00 31 | 49.0 |
jdk1.6.0_01 | -target 1.4 -source 1.4 | 00 00 00 30 | 48.0 |
jdk1.7.0 | 不带(默认为 -target 1.6) | 00 00 00 32 | 50.0 |
jdk1.7.0 | -target 1.7 | 00 00 00 33 | 51.0 |
jdk1.7.0 | -target 1.4 -source 1.4 | 00 00 00 30 | 48.0 |
Apache Harmony 5.0M3 | 不带(默认为 -target 1.2) | 00 00 00 2E | 46.0 |
Apache Harmony 5.0M3 | -target 1.4 | 00 00 00 30 | 48.0 |
上面比较是 Windows 平台下的 JDK 编译器的情况,我们可以此作些总结:
1) -target 1.1 时 有次版本号,target 为 1.2 及以后都只用主版本号了,次版本号为 0
2) 从 1.1 到 1.4 语言差异比较小,所以 1.2 到 1.4 默认的 target 都不是自身相对应版本
3) 1.5 语法变动很大,所以直接默认 target 就是 1.5。也因为如此用 1.5 的 JDK 要生成目标为 1.4 的代码,光有 -target 1.4 不够,必须同时带上 -source 1.4,指定源码的兼容性,1.6/1.7 JDk 生成目标为 1.4 的代码也如此。
4) 1.6 编译器显得较为激进,默认参数就为 -target 1.6。因为 1.6 和 1.5 的语法无差异,所以用 -target 1.5 时无需跟着 -source 1.5。
5) 注意 1.7 编译的默认 target 为 1.6
6) 其他第三方的 JDK 生成的 Class 文件格式版本号同对应 Sun 版本 JDK
7) 最后一点最重要的,某个版本的 JVM 能接受 class 文件的最大主版本号不能超过对应 JDK 带相应 target 参数编译出来的 class 文件的版本号。
上面那句话有点长,一口气读过去不是很好理解,举个例子:1.4 的 JVM 能接受最大的 class 文件的主版本号不能超过用 1.4 JDK 带参数 -target 1.4 时编译出的 class 文件的主版本号,也就是 48。
因为 1.5 JDK 编译时默认 target 为 1.5,出来的字节码 major.minor version 是 49.0,所以 1.4 的 JVM 是无法接受的,只有抛出错误。
那么又为什么从 1.1 到 1.2、从 1.2 到 1.3 或者从 1.3 到 1.4 的 JDK 升级不会发生 Unsupported major.minor version 的错误呢,那是因为 1.2/1.3/1.4 都保持了很好的二进制兼容性,看看 1.2/1.3/1.4 的默认 target 分别为 1.1/1.1/1.2 就知道了,也就是默认情况下1.4 JDK 编译出的 class 文件在 JVM 1.2 下都能加载执行,何况于 JVM 1.3 呢?(当然要去除使用了新版本扩充的 API 的因素)
六:找到问题解决的方法
那么现在如果碰到这种问题该知道如何解决了吧,还会像我所见到有些兄弟那样,去找个 1.4 的 JDK 下载安装,然后用其重新编译所有的代码吗?其实大可不必如此费神,我们一定还记得 javac 还有个 -target 参数,对啦,可以继续使用 1.5 JDK,编译时带上参数 -target 1.4 -source 1.4 就 OK 啦,不过你一定要对哪些 API 是 1.5 JDK 加入进来的了如指掌,不能你的 class 文件拿到 JVM 1.4 下就会 method not found。目标 JVM 是 1.3 的话,编译选项就用 -target 1.3 -source 1.3 了。
相应的如果使用 ant ,它的 javac 任务也可对应的选择 target 和 source
<javac target="1.4" source="1.4" ............................/>
如果是在开发中,可以肯定的是现在真正算得上是 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 文件处理一下就行了。
本文原始出处:
http://www.blogjava.net/Unmi/archive/2007/12/04/165035.html
发表评论
-
SpringBoot Fat Jar解压运行
2018-06-28 21:40 2179SpringBoot已经成为当前最流行的微服务 ... -
一句话实现五星评分显示
2018-06-05 08:31 943Python: rate = 1 #rate 取值 ... -
来算google的可视化编程工具——Blockly,不仅仅是玩具
2017-10-16 21:34 32711Blockly - 来自Google的可 ... -
安卓动态分析工具 Inspeckage
2017-08-07 08:46 0工具介绍 一个基于Xposed 开发的应用动态分析工具 g ... -
Android逆向之旅---静态方式破解微信获取聊天记录和通讯录信息
2017-08-07 08:37 0一、猜想数据存放路径 微信现在是老少皆宜,大街小巷都在使用 ... -
破解微信数据库 并查询数据上传服务器
2017-08-07 08:29 0由于工作需求破解了微信的数据库 并获取想要的信息上传服 ... -
安卓黑科技之HOOK详解
2017-08-07 08:21 0本文带大家进入到安卓另一个世界 互联网攻防大战 Xpos ... -
安卓逆向之基于Xposed-ZjDroid脱壳
2017-08-07 08:18 0前言 之前介绍了普通常见的反编译模式 但对于使用了 360 ... -
十步以内完成精细web打印
2017-06-21 11:44 7288注意: 康虎云报表组 ... -
浏览器端精准打印或套打组件
2017-01-18 13:05 6638注意: 康虎云报表 ... -
疯狂软件对Oracle放弃Java EE的看法
2016-08-14 22:38 472来源:http://javaligang ... -
几个Java相关的思维导图
2016-03-17 13:07 911来源:http://blog.csdn.net/jackf ... -
jasperReport Applet 打印
2016-02-01 16:33 824Applet方式的原理是本地下载Applet以及Jas ... -
为Java说句公道话
2016-01-24 10:59 669为Java说句公道话 有些 ... -
Mybatis Generator配置详解(中文)_转
2015-12-17 16:44 868来自: http://www.jianshu.com/p/e ... -
一个提供大量数据模型的网站
2015-12-17 14:00 890网站地址是:http://www.databaseansw ... -
采用ajp代理模式配置Apache+tomcat实现负载均衡(转)
2015-11-13 10:22 812这一种方法,配置简单,性能也高。附AJP介绍: AJP ... -
MyBatis配置文件修改侦测及重载的实现
2015-07-31 13:53 2280MyBatis配置文件修改侦测及重载的实现: /** ... -
Spring optional @PathVariable?
2015-07-09 13:13 864Q: Is it possible to somehow ... -
The forked VM terminated without saying properly goodbye. VM crash or System.exi
2015-07-07 18:22 3996The forked VM terminated witho ...
相关推荐
本文将对Java常见面试题进行总结和解析,旨在为准备面试的Java开发者提供全面而深入的学习参考。...建议读者结合实际代码示例和项目经验,深入理解和掌握这些知识点,并不断练习和总结,以提高自己的面试成
fail-fast俗称快速失败,是在多线程进行迭代操作时产生冲突的一种异常抛出机制,下面我们就由ArrayList来深入理解Java中的fail-fast机制.
此外,本书的配套光盘还免费提供了价值人民币330元的java教学视频,对java语言进行了全面讲解,帮助一些不会java语言的读者快速地从java基础知识的学习中过渡到java web的学习与开发上. 第1部分 xml篇. 第1章 xml...
此外,本书的配套光盘还免费提供了价值人民币330元的java教学视频,对java语言进行了全面讲解,帮助一些不会java语言的读者快速地从java基础知识的学习中过渡到java web的学习与开发上. 第1部分 xml篇. 第1章 xml...
此外,本书的配套光盘还免费提供了价值人民币330元的java教学视频,对java语言进行了全面讲解,帮助一些不会java语言的读者快速地从java基础知识的学习中过渡到java web的学习与开发上. 第1部分 xml篇. 第1章 xml...
此外,本书的配套光盘还免费提供了价值人民币330元的java教学视频,对java语言进行了全面讲解,帮助一些不会java语言的读者快速地从java基础知识的学习中过渡到java web的学习与开发上. 第1部分 xml篇. 第1章 xml...
CommonJS旨在将运行在浏览器之外的JS进行标准化,并已经解决了大量的JS问题(如全局命名冲突)。Node对CommonJS的实现中,每个模块都会被封装在一个单独的JS文件中,即一个文件就是一个模块,而文件路径就是模块名。...
通过实践,学生能够更深入地理解和掌握所学的概念、原理和技术,并将其转化为实际可用的解决方案。 技能培养:计算机课程设计帮助学生培养实际编程和解决问题的能力。通过设计和实现项目,学生能够锻炼他们的编程...
9.2.2 理解结构和类的区别 162 9.2.3 声明结构变量 163 9.2.4 理解结构的初始化 164 9.2.5 复制结构变量 167 第9章快速参考 170 第10章 使用数组和集合 171 10.1 什么是数组 171 10.1.1 声明数组变量 171 ...
本书是一本Android进阶类书籍,采用理论、源码和实践相结合的方式来阐述高水准的Android应用开发要点。本书从三个方面来组织内容。第一,介绍Android开发者不容易掌握的一些知识点;第二,结合Android源代码和应用层...
/ 154 3.5.1 常见的滑动冲突场景 / 155 3.5.2 滑动冲突的处理规则 / 156 3.5.3 滑动冲突的解决方式 / 157 第4章 View的工作原理 / 174 4.1 初识View Root和Decor View / 174 4.2 理解Measure Spec / ...
第7章 Android动画深入分析 / 265 7.1 View动画 / 265 7.1.1 View动画的种类 / 265 7.1.2 自定义View动画 / 270 7.1.3 帧动画 / 272 7.2 View动画的特殊使用场景 / 273 7.2.1 LayoutAnimation / 273 ...
2分法-通用存储过程分页(top max模式)版本(性能相对之前的not in版本极大提高) 分页存储过程:排序反转分页法 优化后的通用分页存储过程 sql语句 一些Select检索高级用法 SQL server 2005中新增的排序函数及应用 ...
ANTLR是一款强大的语法分析器生成工具,可用于读取、处理、执行和翻译结构化的文本或二...不过,假如你现在没有这样的需求,我仍然建议你阅读本书,因为它能够开拓你的眼界,让你深入实现层面加深对编程语言的理解。
14.4 继承中关于属性的一些问题.169 14.5 小 结 .172 第四部分 深入了解 C#.174 第十五章 接 口 .174 15.1 组件编程技术 .174 15.2 接 口 定 义 .177 15.3 接口的成员 .178 15.4 接口的实现 .182 ...