Unsupported major.minor version 51.0怎么解决

一：要解决的问题

我们在尝鲜JDK1.5的时候，相信不少人遇到过Unsupportedmajor.minorversion49.0错误，当时定会茫然不知所措。因为刚开始那会儿，网上与此相关的中文资料还不多，现在好了，网上一找就知道是如何解决，大多会告诉你要使用JDK1.4重新编译。那么至于为什么，那个major.minor究竟为何物呢？这就是本篇来讲的内容，以使未错而先知。

我觉得我是比较幸运的，因为在遇到那个错误之前已研读过《深入Java虚拟机》第二版，英文原书名为《InsidetheJavaVirtualMachine》(SecondEdition)，看时已知晓major.minor藏匿于何处，但没有切身体会，待到与Unsupportedmajor.minorversion49.0真正会面试，正好是给我验证了一个事实。

首先我们要对Unsupportedmajor.minorversion49.0建立的直接感觉是：JDK1.5编译出来的类不能在JVM1.4下运行，必须编译成JVM1.4下能运行的类。(当然，也许你用的还是JVM1.3或JVM1.2，那么就要编译成目标JVM能认可的类)。这也解决问题的方向。

二：major.minor栖身于何处

何谓major.minor，且又居身于何处呢？先感性认识并找到major.minor来。

写一个JavaHelloWorld!代码，然后用JDK1.5的编译器编译成，HelloWorld.java

packagecom.unmi;

publicclassHelloWorld

{

publicstaticvoidmain(String[]args)

{

System.out.println("Hello,World!");

}

}

packagecom.unmi;publicclassHelloWorld{publicstaticvoidmain(String[]args){System.out.println("Hello,World!");}}

用JDK1.5的javac-d.HelloWorld.java编译出来的字节码HelloWorld.class用UltraEdit打开来的内容如图所示：

从上图中我们看出来了什么是major.minorversion了，它相当于一个软件的主次版本号，只是在这里是标识的一个JavaClass的主版本号和次版本号，同时我们看到minor_version为0x0000，major_version为0x0031，转换为十制数分别为0和49，即major.minor就是49.0了。

三：何谓major.minor以及何用

Class文件的第5-8字节为minor_version和major_version。Javaclass文件格式可能会加入新特性。class文件格式一旦发生变化，版本号也会随之变化。对于JVM来说，版本号确定了特定的class文件格式，通常只有给定主版本号和一系列次版本号后，JVM才能够读取class文件。如果class文件的版本号超出了JVM所能处理的有效范围，JVM将不会处理该class文件。

在Sun的JDK1.0.2发布版中，JVM实现支持从45.0到45.3的class文件格式。在所有JDK1.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命令行中指定了-target1.2标志，1.2版本的编译器将产生版本号为46.0的class文件。1.0或1.1版本的JVM上不能运行使用-target1.2标志所产生的class文件。

JVM实现的第二版中修改了对class文件主版本号和次版本号的解释。对于第二版而言，class文件的主版本号与Java平台主发布版的版本号保持一致(例如：在Java2平台发布版上，主版本号从45升至46)，次版本号与特定主平台发布版的各个发布版相关。因此，尽管不同的class文件格式可以由不同的版本号表示，但版本号不一样并不代表class文件格式不同。版本号不同的原因可能只是因为class文件由不同发布版本的java平台产生，可能class文件的格式并没有改变。

上面三段节选自《深入Java虚拟机》，啰嗦一堆，JDK1.2开启了Java2的时代，但那个年代仍然离我们很远，我们当中很多少直接跳在JDK1.4上的，我也差不多，只是项目要求不得不在一段时间里委屈在JDK1.3上。不过大致我们可以得到的信息就是每个版本的JDK编译器编译出的class文件中都带有一个版本号，不同的JVM能接受一个范围class版本号，超出范围则要出错。不过一般都是能向后兼容的，知道Sun在做Solaris的一句口号吗？保持对先前版本的100%二进制兼容性，这也是对客户的投资保护。

四：其他确定class的major.minorversion办法

1）Eclipse中查看

Eclipse3.3加入的新特征，当某个类没有关联到源代码，打开它会显示比较详细的类信息，当然还未到源码级别了，看下图是打开2.0spring.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:ApacheAnt1.7.0

Created-By:ApacheAnt

Package:org.apache.velocity

Build-Jdk:1.4.2_08

Extension-Name:velocity

我们看到是用ant打包，构建用的JDK是1.4.2_08，用1.4编译的类在1.4JVM中当然能运行。如果那人用1.5的JDK来编译，然后用JDK1.4+ANT来打包就太无聊了。

·2.0spring.jar的META-INFO\MANIFEST部份内容

Manifest-Version:1.0

Ant-Version:ApacheAnt1.6.5

Created-By:1.5.0_08-b03(SunMicrosystemsInc.)

Implementation-Title:SpringFramework

这下要注意啦，它是用的JDK1.5来编译的，那么它是否带了-target1.4或-target1.3来编译的呢？确实是的，可以查看类的二进制文件，这是最保险的。所在spring-2.0.jar也可以在1.4JVM中加载执行。

·自已一个项目中用ant打的jar包的META-INFO\MANIFEST

Manifest-Version:1.0

Ant-Version:ApacheAnt1.7.0

Created-By:1.4.2-b28(SunMicrosystemsInc.)

用的是JDK1.4构建打包的。

第一第二种办法能明确知道major.minorversion，而第三种方法应该也没问题，但是碰到变态构建就难说了，比如谁把那个META-INFO\MANIFEST打包后换了也未可知。直接查看类的二进制文件的方法可以万分保证，准确无误，就是工具篡改我也认了。

五：编译器比较及症节之所在

现在不妨从JDK1.1到JDK1.7编译器编译出的class的默认minor.majorversion吧。（又走到Sun的网站上翻腾出我从来都没用过的古董来）

JDK编译器版本target参数十六进制minor.major十进制minor.major

jdk1.1.8不能带target参数0003002D45.3

jdk1.2.2不带(默认为-target1.1)0003002D45.3

jdk1.2.2-target1.20000002E46.0

jdk1.3.1_19不带(默认为-target1.1)0003002D45.3

jdk1.3.1_19-target1.30000002F47.0

j2sdk1.4.2_10不带(默认为-target1.2)0000002E46.0

j2sdk1.4.2_10-target1.40000003048.0

jdk1.5.0_11不带(默认为-target1.5)0000003149.0

jdk1.5.0_11-target1.4-source1.40000003048.0

jdk1.6.0_01不带(默认为-target1.6)0000003250.0

jdk1.6.0_01-target1.50000003149.0

jdk1.6.0_01-target1.4-source1.40000003048.0

jdk1.7.0不带(默认为-target1.6)0000003250.0

jdk1.7.0-target1.70000003351.0

jdk1.7.0-target1.4-source1.40000003048.0

ApacheHarmony5.0M3不带(默认为-target1.2)0000002E46.0

ApacheHarmony5.0M3-target1.40000003048.0

上面比较是Windows平台下的JDK编译器的情况，我们可以此作些总结：

1)-target1.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的代码，光有-target1.4不够，必须同时带上-source1.4，指定源码的兼容性，1.6/1.7JDk生成目标为1.4的代码也如此。

4)1.6编译器显得较为激进，默认参数就为-target1.6。因为1.6和1.5的语法无差异，所以用-target1.5时无需跟着-source1.5。

5)注意1.7编译的默认target为1.6

6)其他第三方的JDK生成的Class文件格式版本号同对应Sun版本JDK

7)最后一点最重要的，某个版本的JVM能接受class文件的最大主版本号不能超过对应JDK带相应target参数编译出来的class文件的版本号。

上面那句话有点长，一口气读过去不是很好理解，举个例子：1.4的JVM能接受最大的class文件的主版本号不能超过用1.4JDK带参数-target1.4时编译出的class文件的主版本号，也就是48。

因为1.5JDK编译时默认target为1.5，出来的字节码major.minorversion是49.0，所以1.4的JVM是无法接受的，只有抛出错误。

那么又为什么从1.1到1.2、从1.2到1.3或者从1.3到1.4的JDK升级不会发生Unsupportedmajor.minorversion的错误呢，那是因为1.2/1.3/1.4都保持了很好的二进制兼容性，看看1.2/1.3/1.4的默认target分别为1.1/1.1/1.2就知道了，也就是默认情况下1.4JDK编译出的class文件在JVM1.2下都能加载执行，何况于JVM1.3呢？（当然要去除使用了新版本扩充的API的因素）

六：找到问题解决的方法

那么现在如果碰到这种问题该知道如何解决了吧，还会像我所见到有些兄弟那样，去找个1.4的JDK下载安装，然后用其重新编译所有的代码吗？其实大可不必如此费神，我们一定还记得javac还有个-target参数，对啦，可以继续使用1.5JDK，编译时带上参数-target1.4-source1.4就OK啦，不过你一定要对哪些API是1.5JDK加入进来的了如指掌，不能你的class文件拿到JVM1.4下就会methodnotfound。目标JVM是1.3的话，编译选项就用-target1.3-source1.3了。

相应的如果使用ant，它的javac任务也可对应的选择target和source

<javactarget="1.4"source="1.4"............................/>

如果是在开发中，可以肯定的是现在真正算得上是JAVAIDE对于工程也都有编译选项设置目标代码的。例如Eclipse的项目属性中的JavaCompiler设置，如图

自已设定编译选项，你会看到选择不同的compilercompliancelevel是，Generatedclassfilescompatibility和Sourcecompatibility也在变，你也可以手动调整那两项，手动设置后你就不用很在乎用的什么版本的编译器了，只要求他生成我们希望的字节码就行了，再引申一下就是即使源代码是用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的话；更有甚者，你还用了JDK1.5的新特性，譬如泛型、自动拆装箱、枚举等的话，那你用-target1.4-source1.4就没法编译通过，不得不重新整理代码。那么告诉你最后一招，不需要再从源代码着手，直接转换你所正常编译出的字节码，继续享用那些新的特性，新的API，那就是：请参考之前的一篇日志：Retrotranslator让你用JDK1.5的特性写出的代码能在JVM1.4中运行，我就是这么用的，做好测试就不会有问题的。

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

这是一个因为拷贝Tomcat而产生的Unsupportedmajor.minorversion49.0错误。情景是：我本地安装的是JDK1.5，然后在网上找了一个EXE的Tomcat安装文件安装了并且可用。后来同事要一个Tomcat，不想下载或安装，于是根据我以往的经验是把我的Tomcat整个目录拷给他应该就行了，结果是拿到他那里浏览jsp文件都出现Unsupportedmajor.minorversion49.0错误，可以确定的是他安装的是1.4的JDK，但我还是有些纳闷，先前对这个问题还颇有信心的我傻眼了。惯性思维是编译好的class文件拿到低版本的JVM会出现如是异常，可现并没有用已JDK1.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.4JDK的tools.jar替换了Tomcat的就OK啦。

八：小结

其实理解major.minor就像是我们可以这么想像，同样是微软件的程序，32位的应用程序不能拿到16位系统中执行那样。

如果我们发布前了解到目标JVM版本，知道怎么从javaclass文件中看出major.minor版本来，就不用等到服务器报出异常才着手去解决，也就能预知到可能发生的问题。

其他时候遇到这个问题应具体解决，总之问题的根由是低版本的JVM无法加载高版本的class文件造成的，找到高版本的class文件处理一下就行了