http://blog.csdn.net/shan9liang/article/details/17266519

**********************************************

問題起源：

今天再在ESB調用WebService測試，需要在jboss上部署一個ejb項目(ejb發布的webservice)，過去部署好好的代碼，這次再部署上去竟然報錯了，log記錄的錯誤如下：

[org.jboss.detailed.classloader.ClassLoaderManager] (HDScanner) Unexpected error during load of:com.jialin.ejb.UserManagerBean

java.lang.UnsupportedClassVersionError: com/jialin/ejb/UserManagerBean : Unsupported major.minor version 51.0

…………

…………

2013-12-11 14:48:34,329 ERROR

[org.jboss.kernel.plugins.dependency.AbstractKernelController]

(HDScanner) Error installing to PostClassLoader:

name=vfszip:/F:/jboss-5.1.0.GA/server/default/deploy/ejb_webservice1.jar/

state=ClassLoader mode=Manual requiredState=PostClassLoader

org.jboss.deployers.spi.DeploymentException: Cannot process metadata

…………

…………

開始尋找解決方案：

環境：

jdk 1.6；

jboss 5.1.0.GA

eclipse 4.2

這里可以配置的jdk，還有個java compiler中可以配置compiler level(如圖中紅色框)。這兩個東西就是這個問題的關鍵。

在eclipse中進行開發的時候，build path 中JDK進行類庫的編譯(就是你使用類在不在這個JDK中)，java

compiler compliance level是對這個項目語法的編譯(就是你的項目中語法的正確與否)，也可以把java compiler

compliance level中配置的編譯版本號的作用看作是你這個項目將來開發完畢之后，要放到服務器上運行，那個服務器上JDK的運行版本。

而我的問題就出在build path中配置1.6的JDK，java compiler compliance level中配置的1.7(因為以前我用過一段時間1.7)

而在jboss服務器上是1.6的JDK，就報了那個錯誤，說是編譯所用的jdk(1.7)比運行所用的jdk(1.6)高了，這是錯誤的。

放在其他人機器上之所以不報錯，是因為他的jboss使用的jdk恰恰是1.7。這個版本是向下兼容的。

再拿個被人舉過的例子，如果JDK1.4不能使用泛型。而java compiler compliance

level設置的是你寫好的JAVA代碼按照什么JDK版本級別編譯，例如：設置的是1.4，編譯出來的class文件可以在1.4以上的JRE上運行，如果用的是5.0級別編譯，就不能運行在1.4的環境里面，會提示版本過高。

總結：

1、在開發和部署過程中，最安全的做法，是build path ， java complier compliance level，jboss服務器配置的JDK都保持一致，就不會出現任何問題的。

2、我們常常關注build path中jdk的版本和jboss中jdk版本，殊不知他們是通過?java complier compliance level聯系起來的。

有時候我們并不能僅僅按照網上的解決步驟把問題解決了就算萬事大吉了。我不得不承認這是解決問題的捷徑，但從捷徑走過后，我們應分析和總結問題的來龍去脈，真正理解它的本質，才算是一種積累，因為網上的解決方案永遠是針對過時的技術，新技術暴露的問題依然會讓你手足無措，但幸好技術的本質是不容易改變的，所以說，抓住本質，才是常勝之道。

不知道從什么時候開始，已經不再滿足于解決問題就好，呵呵。

總結

以上是生活随笔為你收集整理的java compliance_java complier compliance level问题引发的思考的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。