`
zengjinliang
  • 浏览: 308790 次
  • 性别: Icon_minigender_1
  • 来自: 广州
社区版块
存档分类
最新评论

再看Unsupported major.minor version 49.0

阅读更多
一:要解决的问题

我们在尝鲜 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 打开来的内容如图所示:





从上图中我们看出来了什么是 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 文件处理一下就行了。
  • 大小: 81.3 KB
  • 大小: 268.3 KB
  • 大小: 319.7 KB
  • 大小: 242.7 KB
分享到:
评论

相关推荐

    Unsupported major.minor version 51.0

    "Unsupported major.minor version 51.0" Unsupported major.minor version 51.0 错误是 Java 开发中常见的一种错误,原因是 Java 类文件的版本不匹配。下面我们将详细介绍该错误的原因、解决办法以及相关的 Java ...

    启动Tomcat报错Unsupported major.minor version xxx的解决方法

    Tomcat报错Unsupported major.minor version xxx的解决方法 一、问题背景 在Java开发过程中,我们经常会遇到Tomcat报错Unsupported major.minor version xxx的问题。这是因为编译的JDK版本和运行时所用的JDK版本不...

    Java 中解决Unsupported major.minor version 51.0的问题

    在Java编程中,"Unsupported major.minor version 51.0"是一个常见的错误,它通常发生在尝试使用较旧版本的Java虚拟机(JVM)运行由较新版本的Java编译器编译的代码时。这个错误信息表示JVM无法识别或支持编译后的...

    jdk1.5环境下编译的jar包在JDK1.4环境下运行

    这里我们讨论的焦点是“JDK1.5环境下编译的jar包在JDK1.4环境下运行”所遇到的问题,具体表现为“Unsupported major.minor version 49.0”的错误。这个错误的根源在于Java字节码版本不兼容。Java字节码版本与JDK版本...

    jpeglib_version_61

    JPEG库,全称为Joint Photographic Experts Group,是用于处理JPEG图像格式的标准库,而`jpeglib`是这个库的核心部分。JPEG是一种广泛使用的有损压缩算法,尤其适用于照片和其他连续色调的图像。...

    javarebel.jar

    Javarebel是一个Jvm插件,它能够动态重新装载Java类特性。虽然现在还有些局限性,但它可以显著地增加开发速度。JavaRebel允许一个应用程序(独立的或运行在应用服务器上的应用)重新装载在运行过程中发生的大多数类...

    selenium自动化测试jar包

    包含selenium-server-standalone-3.0.1.jar,selenium-java-2.53.0.jar,selenium-java-2.53.0-srcs.jar及自动化测试所需要的jar包

    Android如何处理带资源文件的JAR

    在Android开发中,有时我们需要将资源文件(如图片、XML配置等)与Java代码一起打包成JAR文件,以便于库或插件的分发。然而,Android原生不支持直接从JAR中读取资源文件,这给开发者带来了挑战。...

    commons-compress包

    Caused by:xxx Unsupported major.minor version 52.0。翻译为中文:(Tomcat)不支持52.0版本的镜像 二、jdk与major.mijor version对应的关系如下 JDK 1.1 = 45 JDK 1.2 = 46 JDK 1.3 = 47 JDK 1.4 = 48 JDK 1.5 = ...

    jackson-2.9.9 jar包【三个包】

    资源包括: jackson-annotations-2.9.9 jackson-core-2.9.9 jackson-databind-2.9.9 Jackson 的核心模块由三部分组成。 jackson-core,核心包,提供基于"流模式"解析的相关 API,它包括 JsonPaser 和 JsonGenerator...

    Android 签名文件找回密码

    3:如果出现 Unsupported major.minor version 52.0 则表示该文件的版本与本地的jdk版本不匹配 经测试 jdk1.7.0使用1.05版本的AndroidKeystore jdk1.8.0使用1.07版本的AndroidKeystore (资源里面两个版本的都有) ...

    Android_Keystore_Password_Recover_1.07.jar

    3:如果出现 Unsupported major.minor version 52.0 则表示该文件的版本与本地的jdk版本不匹配 经测试 jdk1.7.0使用1.05版本的AndroidKeystore jdk1.8.0使用1.07版本的AndroidKeystore (资源里面两个版本的都有) ...

    查看java类版本.pdf

    3. **Unsupported major.minor version 错误**:这个错误通常发生在尝试用一个较新版本的JDK编译的类文件在旧版本的JVM上运行时。例如,JDK 1.5编译的类文件(major_version为49)无法在JVM 1.4或更早版本上运行,...

    MyEclipse 5.0GA + WebLogic 9.2 配置详解

    其次,如果选择J2EE 1.3进行开发,可能会遇到“Unsupported major.minor version 49.0”的错误,这是由于WebLogic 8不支持JDK 1.5导致的。为了解决这个问题,你可以选择使用JDK 1.4重新编译项目,或者升级WebLogic到...

    ssh框架错误总结

    在使用JUnit/StrutsTest时,可能会遇到java.lang.UnsupportedClassVersionError: junit/framework/TestListener (Unsupported major.minor version 49.0)错误。 解决方法:根据JDK版本选择合适的JUnit版本。如果...

    geohash.jar geohash-1.3.0

    geohash官方发布以及maven发布的版本都是基于jdk1.7编译的,碰到jdk1.6的项目会报unsupported major.minor version 51.0错误。这个资源是我基于jdk1.6编译的,执行测试案例都通过了。

    spatial4j.jar spatial4j-0.8.jar

    spatial4j官方发布以及maven发布的版本都是基于jdk1.7编译的,碰到jdk1.6的项目会报unsupported major.minor version 51.0错误。这个资源是我基于jdk1.6编译的,执行测试案例都通过了。

    three.js加载gltf模型

    首先,我们来看`three.js`。这是一个强大的JavaScript库,为Web浏览器提供了创建和操作3D图形的能力。它支持各种3D对象、光照、材质、动画等,并且与许多3D模型格式兼容,包括.gltf和.glb。 `gltf`格式是一种轻量级...

    Retrotranslator

    当我们引入的jar包和本地的jdk版本有冲突的情况下,会报一下错误:java.lang.UnsupportedClassVersionError:com/sun/tools/javac/Main : Unsupported major.minor version 51.0,所以我们需要强制给jar依赖的jdk版本...

Global site tag (gtag.js) - Google Analytics