轉(zhuǎn)自：http://m.tkk7.com/Unmi/archive/2007/12/04/165035.html
一：要解決的問題
我們在嘗鮮 JDK1.5 的時(shí)候，相信不少人遇到過 Unsupported major.minor version 49.0 錯誤，當(dāng)時(shí)定會茫然不知所措。因?yàn)閯傞_始那會兒，網(wǎng)上與此相關(guān)的中文資料還不多，現(xiàn)在好了，網(wǎng)上一找就知道是如何解決，大多會告訴你要使用 JDK 1.4 重新編譯。那么至于為什么，那個 major.minor 究竟為何物呢？這就是本篇來講的內(nèi)容，以使未錯而先知。
我覺得我是比較幸運(yùn)的，因?yàn)樵谟龅侥莻€錯誤之前已研讀過《深入 Java 虛擬機(jī)》第二版，英文原書名為《Inside the Java Virtual Machine》( Second Edition)，看時(shí)已知曉 major.minor 藏匿于何處，但沒有切身體會，待到與 Unsupported major.minor version 49.0 真正會面試，正好是給我驗(yàn)證了一個事實(shí)。
首先我們要對 Unsupported major.minor version 49.0 建立的直接感覺是：JDK1.5 編譯出來的類不能在 JVM 1.4 下運(yùn)行，必須編譯成 JVM 1.4 下能運(yùn)行的類。(當(dāng)然，也許你用的還是 JVM 1.3 或 JVM 1.2，那么就要編譯成目標(biāo) JVM 能認(rèn)可的類)。這也解決問題的方向。
二：major.minor 棲身于何處
何謂 major.minor，且又居身于何處呢？先感性認(rèn)識并找到 major.minor 來。
寫一個 Java Hello World! 代碼，然后用 JDK 1.5 的編譯器編譯成，HelloWorld.java
1
package com.unmi;
2
3public class HelloWorld
4
{
5
public static void main(String[] args)
6
{
7 System.out.println("Hello, World!");
8
}
9
}
10
用 JDK 1.5 的 javac -d . HelloWorld.java 編譯出來的字節(jié)碼 HelloWorld.class 用 UltraEdit 打開來的內(nèi)容如圖所示：
從上圖中我們看出來了什么是 major.minor version 了，它相當(dāng)于一個軟件的主次版本號，只是在這里是標(biāo)識的一個 Java Class 的主版本號和次版本號，同時(shí)我們看到 minor_version 為 0x0000，major_version 為 0x0031，轉(zhuǎn)換為十制數(shù)分別為0 和 49，即 major.minor 就是 49.0 了。
三：何謂 major.minor 以及何用
Class 文件的第 5-8 字節(jié)為 minor_version 和 major_version。Java class 文件格式可能會加入新特性。class 文件格式一旦發(fā)生變化，版本號也會隨之變化。對于 JVM 來說，版本號確定了特定的 class 文件格式，通常只有給定主版本號和一系列次版本號后，JVM 才能夠讀取 class 文件。如果 class 文件的版本號超出了 JVM 所能處理的有效范圍，JVM 將不會處理該 class 文件。
在 Sun 的 JDK 1.0.2 發(fā)布版中，JVM 實(shí)現(xiàn)支持從 45.0 到 45.3 的 class 文件格式。在所有 JDK 1.1 發(fā)布版中的 JVM 都能夠支持版本從 45.0 到 45.65535 的 class 文件格式。在 Sun 的 1.2 版本的 SDK 中，JVM 能夠支持從版本 45.0 到46.0 的 class 文件格式。
1.0 或 1.2 版本的編譯器能夠產(chǎn)生版本號為 45.3 的 class 文件。在 Sun 的 1.2 版本 SDK 中，Javac 編譯器默認(rèn)產(chǎn)生版本號為 45.3 的 class 文件。但如果在 javac 命令行中指定了 -target 1.2 標(biāo)志，1.2 版本的編譯器將產(chǎn)生版本號為 46.0 的 class 文件。1.0 或 1.1 版本的 JVM 上不能運(yùn)行使用-target 1.2 標(biāo)志所產(chǎn)生的 class 文件。
JVM 實(shí)現(xiàn)的 第二版中修改了對 class 文件主版本號和次版本號的解釋。對于第二版而言，class 文件的主版本號與 Java 平臺主發(fā)布版的版本號保持一致(例如：在 Java 2 平臺發(fā)布版上，主版本號從 45 升至 46)，次版本號與特定主平臺發(fā)布版的各個發(fā)布版相關(guān)。因此，盡管不同的 class 文件格式可以由不同的版本號表示，但版本號不一樣并不代表 class 文件格式不同。版本號不同的原因可能只是因?yàn)?class 文件由不同發(fā)布版本的 java 平臺產(chǎn)生，可能 class 文件的格式并沒有改變。
上面三段節(jié)選自《深入 Java 虛擬機(jī)》，啰嗦一堆，JDK 1.2 開啟了 Java 2 的時(shí)代，但那個年代仍然離我們很遠(yuǎn)，我們當(dāng)中很多少直接跳在 JDK 1.4 上的，我也差不多，只是項(xiàng)目要求不得不在一段時(shí)間里委屈在 JDK 1.3 上。不過大致我們可以得到的信息就是每個版本的 JDK 編譯器編譯出的 class 文件中都帶有一個版本號，不同的 JVM 能接受一個范圍 class 版本號，超出范圍則要出錯。不過一般都是能向后兼容的，知道 Sun 在做 Solaris 的一句口號嗎？保持對先前版本的 100% 二進(jìn)制兼容性，這也是對客戶的投資保護(hù)。
四：其他確定 class 的 major.minor version 辦法
1）Eclipse 中查看
Eclipse 3.3 加入的新特征，當(dāng)某個類沒有關(guān)聯(lián)到源代碼，打開它會顯示比較詳細(xì)的類信息，當(dāng)然還未到源碼級別了，看下圖是打開 2.0 spring.jar 中 ClasspathXmlApplicationContext.class 顯示的信息
2）命令 javap -verbose
對于編譯出的 class 文件用 javap -verbose 能顯示出類的 major.minor 版本，見下圖：
3) MANIFEST 文件
把 class 打成的 JAR 包中都會有文件 META-INF\MANIFEST，這個文件一般會有編譯器的信息，下面列幾個包的 META-INF\MANIFEST 文件內(nèi)容大家看看
·Velocity-1.5.jar 的 META-INFO\MANIFEST 部份內(nèi)容
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 打包，構(gòu)建用的JDK是 1.4.2_08，用 1.4 編譯的類在 1.4 JVM 中當(dāng)然能運(yùn)行。如果那人用 1.5 的 JDK 來編譯，然后用 JDK 1.4+ANT 來打包就太無聊了。
·2.0 spring.jar 的 META-INFO\MANIFEST 部份內(nèi)容
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 來編譯的呢？確實(shí)是的，可以查看類的二進(jìn)制文件，這是最保險(xiǎn)的。所在 spring-2.0.jar 也可以在 1.4 JVM 中加載執(zhí)行。
·自已一個項(xiàng)目中用 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 構(gòu)建打包的。
第一第二種辦法能明確知道 major.minor version，而第三種方法應(yīng)該也沒問題，但是碰到變態(tài)構(gòu)建就難說了，比如誰把那個 META-INFO\MANIFEST 打包后換了也未可知。直接查看類的二進(jìn)制文件的方法可以萬分保證，準(zhǔn)確無誤，就是工具篡改我也認(rèn)了。
五：編譯器比較及癥節(jié)之所在
現(xiàn)在不妨從 JDK 1.1 到 JDK 1.7 編譯器編譯出的 class 的默認(rèn) minor.major version 吧。（又走到 Sun 的網(wǎng)站上翻騰出我從來都沒用過的古董來）
| JDK 編譯器版本 |
target 參數(shù) |
十六進(jìn)制 minor.major |
十進(jìn)制 minor.major |
| jdk1.1.8 |
不能帶 target 參數(shù) |
00 03 00 2D |
45.3 |
| jdk1.2.2 |
不帶(默認(rèn)為 -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 |
不帶(默認(rèn)為 -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 |
不帶(默認(rèn)為 -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 |
不帶(默認(rèn)為 -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 |
不帶(默認(rèn)為 -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 |
不帶(默認(rèn)為 -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 |
不帶(默認(rèn)為 -target 1.2) |
00 00 00 2E |
46.0 |
| Apache Harmony 5.0M3 |
-target 1.4 |
00 00 00 30 |
48.0 |
上面比較是 Windows 平臺下的 JDK 編譯器的情況，我們可以此作些總結(jié)：
1) -target 1.1 時(shí) 有次版本號，target 為 1.2 及以后都只用主版本號了，次版本號為 0
2) 從 1.1 到 1.4 語言差異比較小，所以 1.2 到 1.4 默認(rèn)的 target 都不是自身相對應(yīng)版本
3) 1.5 語法變動很大，所以直接默認(rèn) target 就是 1.5。也因?yàn)槿绱擞?1.5 的 JDK 要生成目標(biāo)為 1.4 的代碼，光有 -target 1.4 不夠，必須同時(shí)帶上 -source 1.4，指定源碼的兼容性，1.6/1.7 JDk 生成目標(biāo)為 1.4 的代碼也如此。
4) 1.6 編譯器顯得較為激進(jìn)，默認(rèn)參數(shù)就為 -target 1.6。因?yàn)?nbsp;1.6 和 1.5 的語法無差異，所以用 -target 1.5 時(shí)無需跟著 -source 1.5。
5) 注意 1.7 編譯的默認(rèn) target 為 1.6
6) 其他第三方的 JDK 生成的 Class 文件格式版本號同對應(yīng) Sun 版本 JDK
7) 最后一點(diǎn)最重要的，
某個版本的 JVM 能接受 class 文件的最大主版本號不能超過對應(yīng) JDK 帶相應(yīng) target 參數(shù)編譯出來的 class 文件的版本號。
上面那句話有點(diǎn)長，一口氣讀過去不是很好理解，舉個例子：1.4 的 JVM 能接受最大的 class 文件的主版本號不能超過用 1.4 JDK 帶參數(shù) -target 1.4 時(shí)編譯出的 class 文件的主版本號，也就是 48。
因?yàn)?1.5 JDK 編譯時(shí)默認(rèn) target 為 1.5，出來的字節(jié)碼 major.minor version 是 49.0，所以 1.4 的 JVM 是無法接受的，只有拋出錯誤。
那么又
為什么從 1.1 到 1.2、從 1.2 到 1.3 或者從 1.3 到 1.4 的 JDK 升級不會發(fā)生 Unsupported major.minor version 的錯誤呢，那是因?yàn)?1.2/1.3/1.4 都保持了很好的二進(jìn)制兼容性，看看 1.2/1.3/1.4 的默認(rèn) target 分別為 1.1/1.1/1.2 就知道了，也就是默認(rèn)情況下1.4 JDK 編譯出的 class 文件在 JVM 1.2 下都能加載執(zhí)行，何況于 JVM 1.3 呢？（當(dāng)然要去除使用了新版本擴(kuò)充的 API 的因素）
六：找到問題解決的方法
那么現(xiàn)在如果碰到這種問題該知道如何解決了吧，還會像我所見到有些兄弟那樣，去找個 1.4 的 JDK 下載安裝，然后用其重新編譯所有的代碼嗎？其實(shí)大可不必如此費(fèi)神，我們一定還記得 javac 還有個 -target 參數(shù)，對啦，可以繼續(xù)使用 1.5 JDK，編譯時(shí)帶上參數(shù) -target 1.4 -source 1.4 就 OK 啦，不過你一定要對哪些 API 是 1.5 JDK 加入進(jìn)來的了如指掌，不能你的 class 文件拿到 JVM 1.4 下就會 method not found。目標(biāo) JVM 是 1.3 的話，編譯選項(xiàng)就用 -target 1.3 -source 1.3 了。
相應(yīng)的如果使用 ant ，它的 javac 任務(wù)也可對應(yīng)的選擇 target 和 source
<javac target="1.4" source="1.4" ............................/>
如果是在開發(fā)中，可以肯定的是現(xiàn)在真正算得上是 JAVA IDE 對于工程也都有編譯選項(xiàng)設(shè)置目標(biāo)代碼的。例如 Eclipse 的項(xiàng)目屬性中的 Java Compiler 設(shè)置，如圖
自已設(shè)定編譯選項(xiàng)，你會看到選擇不同的 compiler compliance level 是，Generated class files compatibility 和 Source compatibility 也在變，你也可以手動調(diào)整那兩項(xiàng)，手動設(shè)置后你就不用很在乎用的什么版本的編譯器了，只要求他生成我們希望的字節(jié)碼就行了，再引申一下就是即使源代碼是用 VB 寫的，只要能編譯成 JVM 能執(zhí)行的字節(jié)碼都不打緊。在其他的 IDE 也能找到相應(yīng)的設(shè)置對話框的。
其他時(shí)候，你一定要知道當(dāng)前的 JVM 是什么版本，能接受的字節(jié)碼主版本號是多少（可對照前面那個表）。獲息當(dāng)前 JVM 版本有兩種途徑：
第一：如果你是直接用 java 命令在控制臺執(zhí)行程序，可以用 java -version 查看當(dāng)前的 JVM 版本，然后確定能接受的 class 文件版本
第二：如果是在容器中執(zhí)行，而不能明確知道會使用哪個 JVM，那么可以在容器中執(zhí)行的程序中加入代碼 System.getProperty("java.runtime.version"); 或 System.getProperty("java.class.version")，獲得 JVM 版本和能接受的 class 的版本號。
最后一絕招，如果你不想針對低版本的 JVM 用 target 參數(shù)重新編譯所有代碼；如果你仍然想繼續(xù)在代碼中用新的 API 的話；更有甚者，你還用了 JDK 1.5 的新特性，譬如泛型、自動拆裝箱、枚舉等的話，那你用 -target 1.4 -source 1.4 就沒法編譯通過，不得不重新整理代碼。那么告訴你最后一招，不需要再從源代碼著手，直接轉(zhuǎn)換你所正常編譯出的字節(jié)碼，繼續(xù)享用那些新的特性，新的 API，那就是：請參考之前的一篇日志：
Retrotranslator讓你用JDK1.5的特性寫出的代碼能在JVM1.4中運(yùn)行，我就是這么用的，做好測試就不會有問題的。
七：再議一個實(shí)際發(fā)生的相關(guān)問題
這是一個因?yàn)榭截?Tomcat 而產(chǎn)生的 Unsupported major.minor version 49.0 錯誤。情景是：我本地安裝的是 JDK 1.5，然后在網(wǎng)上找了一個 EXE 的 Tomcat 安裝文件安裝了并且可用。后來同事要一個 Tomcat，不想下載或安裝，于是根據(jù)我以往的經(jīng)驗(yàn)是把我的 Tomcat 整個目錄拷給他應(yīng)該就行了，結(jié)果是拿到他那里瀏覽 jsp 文件都出現(xiàn) Unsupported major.minor version 49.0 錯誤，可以確定的是他安裝的是 1.4 的 JDK，但我還是有些納悶，先前對這個問題還頗有信心的我傻眼了。慣性思維是編譯好的 class 文件拿到低版本的 JVM 會出現(xiàn)如是異常，可現(xiàn)并沒有用已 JDK 1.5 編譯好的類要執(zhí)行啊。
后來仔細(xì)看異常信息，終于發(fā)現(xiàn)了 %TOMCAT_HOME%\common\lib\tools.jar 這一眉目，因?yàn)?jsp 文件需要依賴它來編譯，打來這個 tools.jar 中的一個 class 文件來看看，49.0，很快我就明白原來這個文件是在我的機(jī)器上安裝 Tomcat 時(shí)由 Tomcat 安裝程序從 %JDK1.5%\lib 目錄拷到 Tomcat 的 lib 目錄去的，造成在同事機(jī)器上編譯 JSP 時(shí)是 1.4 的 JVM 配搭著 49.0 的 tools.jar，那能不出錯，于是找來 1.4 JDK 的 tools.jar 替換了 Tomcat 的就 OK 啦。
八：小結(jié)
其實(shí)理解 major.minor 就像是我們可以這么想像，同樣是微軟件的程序，32 位的應(yīng)用程序不能拿到 16 位系統(tǒng)中執(zhí)行那樣。
如果我們發(fā)布前了解到目標(biāo) JVM 版本，知道怎么從 java class 文件中看出 major.minor 版本來，就不用等到服務(wù)器報(bào)出異常才著手去解決，也就能預(yù)知到可能發(fā)生的問題。
其他時(shí)候遇到這個問題應(yīng)具體解決，總之問題的根由是低版本的 JVM 無法加載高版本的 class 文件造成的，找到高版本的 class 文件處理一下就行了。