2008/6/9

[轉]明明白白Unsupported major.minor version 49.0的錯誤

轉載自http://www.blogjava.net/Unmi/archive/2007/12/04/165035.html
一:要解決的問題

我 們在嘗鮮 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

  1. package com.unmi;
  2. public class HelloWorld
  3. {
  4. public static void main(String[] args)
  5. {
  6. System.out.println("Hello, World!");
  7. }
  8. }


用 JDK 1.5 的 javac -d . HelloWorld.java 編譯出來的字節碼 HelloWorld.class 用 UltraEdit 打開來的內容如圖所示:

HelloWorldClassUnmi.jpg


從 上圖中我們看出來了什麼是 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 顯示的信息

eclipseclass1.jpg


2)命令 javap -verbose
對於編譯出的 class 文件用 javap -verbose 能顯示出類的 major.minor 版本,見下圖:


JavapVerboseUnmi.jpg

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 2D45.3
jdk1.2.2不帶(默認為 -target 1.1)00 03 00 2D45.3
jdk1.2.2-target 1.200 00 00 2E46.0
jdk1.3.1_19不帶(默認為 -target 1.1)00 03 00 2D45.3
jdk1.3.1_19-target 1.300 00 00 2F47.0
j2sdk1.4.2_10不帶(默認為 -target 1.2)00 00 00 2E46.0
j2sdk1.4.2_10-target 1.400 00 00 3048.0
jdk1.5.0_11不帶(默認為 -target 1.5)00 00 00 3149.0
jdk1.5.0_11-target 1.4 -source 1.400 00 00 3048.0
jdk1.6.0_01不帶(默認為 -target 1.6)00 00 00 3250.0
jdk1.6.0_01-target 1.500 00 00 3149.0
jdk1.6.0_01-target 1.4 -source 1.400 00 00 3048.0
jdk1.7.0不帶(默認為 -target 1.6)00 00 00 3250.0
jdk1.7.0-target 1.700 00 00 3351.0
jdk1.7.0-target 1.4 -source 1.400 00 00 3048.0
Apache Harmony 5.0M3不帶(默認為 -target 1.2)00 00 00 2E46.0
Apache Harmony 5.0M3-target 1.400 00 00 3048.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



如果是在開發中,可以肯定的是現在真正算得上是 JAVA IDE 對於工程也都有編譯選項設置目標代碼的。例如 Eclipse 的項目屬性中的 Java Compiler 設置,如圖


EclipseCompiler.JPG


自 已設定編譯選項,你會看到選擇不同的 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 文件處理一下就行了。

沒有留言:

JPA+complex key+custom Query

  來源: https://www.cnblogs.com/520playboy/p/6512592.html   整個來說,就是有複合主鍵 然後要使用  public interface XxXXxx DAO extends CrudRepository<Tc...