转java.lang.UnsupportedClassVersionError: major.minor version error
上一篇 / 下一篇 2012-05-15 15:06:15 / 个人分类:Java
一:要解决的问题
我们在尝鲜 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 的网站上翻腾出我从来都没用过的古董来)
上面比较是 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。
<SPAN style="WIDOWS: 2; TEXT-TRANSFORM. none; BACKGROUND-COLOR: rgb(255,255,255); TEXT-INDENT: 0px; DISPLAY: inline !impor
我们在尝鲜 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
01.
package
com.unmi;
02.
03.
public
class
HelloWorld
04.
{
05.
public
static
void
main(String[] args)
06.
{
07.
System.out.println(
"Hello, World!"
);
08.
}
09.
}
用 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。
<SPAN style="WIDOWS: 2; TEXT-TRANSFORM. none; BACKGROUND-COLOR: rgb(255,255,255); TEXT-INDENT: 0px; DISPLAY: inline !impor
TAG:
标题搜索
日历
|
|||||||||
日 | 一 | 二 | 三 | 四 | 五 | 六 | |||
1 | 2 | 3 | 4 | ||||||
5 | 6 | 7 | 8 | 9 | 10 | 11 | |||
12 | 13 | 14 | 15 | 16 | 17 | 18 | |||
19 | 20 | 21 | 22 | 23 | 24 | 25 | |||
26 | 27 | 28 | 29 | 30 | 31 |
数据统计
- 访问量: 4547
- 日志数: 11
- 图片数: 1
- 建立时间: 2012-02-16
- 更新时间: 2012-07-15