天天看点

在装2个不同版本JDK时遇到了这个问题

一:要解决的问题

我们在尝鲜 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

package com.unmi;   

public class helloworld   

{   

    public static void main(string[] args)   

    {   

        system.out.println("hello, world!");   

    }   

}  

package com.unmi;public class helloworld{ public static void main(string[] args) { system.out.println("hello, world!"); }}

用 jdk 1.5 的 javac -d .  helloworld.java 编译出来的字节码 helloworld.class 用 ultraedit 打开来的内容如图所示:

在装2个不同版本JDK时遇到了这个问题

从上图中我们看出来了什么是 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个不同版本JDK时遇到了这个问题

2)命令 javap -verbose

       对于编译出的 class 文件用 javap -verbose 能显示出类的 major.minor 版本,见下图:

在装2个不同版本JDK时遇到了这个问题

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 部份内容

                  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

                  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)

-target 1.2

00 00   00 2e

46.0

jdk1.3.1_19

-target 1.3

00 00   00 2f

47.0

j2sdk1.4.2_10

不带(默认为 -target 1.2)

-target 1.4

00 00   00 30

48.0

jdk1.5.0_11

不带(默认为 -target 1.5)

00 00   00 31

49.0

-target 1.4 -source 1.4

jdk1.6.0_01

不带(默认为 -target 1.6)

00 00   00 32

50.0

-target 1.5

jdk1.7.0

-target 1.7

00 00   00 33

51.0

apache harmony 5.0m3

上面比较是 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 设置,如图

在装2个不同版本JDK时遇到了这个问题

自已设定编译选项,你会看到选择不同的 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 的版本号。

七:再议一个实际发生的相关问题

这是一个因为拷贝 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 文件处理一下就行了