java complier compliance level and jdk version

1、熟悉一下問題前因後果

轉載自 點擊

環境：

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的環境裏面，會提示版本太高。

總結：

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

二、咱們經常關注build path中jdk的版本和jboss中jdk版本，卻不知他們是經過 java complier compliance level聯繫起來的。

有時候咱們並不能僅僅按照網上的解決步驟把問題解決了就算萬事大吉了。我不得不認可這是解決問題的捷徑，但從捷徑走事後，咱們應分析和總結問題的前因後果，真正理解它的本質，纔算是一種積累，由於網上的解決方案永遠是針對過期的技術，新技術暴露的問題依然會讓你手足無措，但幸虧技術的本質是不容易改變的，因此說，抓住本質，纔是常勝之道。

2、各路說法

2.1 java compiler compliance leve 是爲了兼容在目標服務器上面運行

Not quite. But first of all, each project has the option to set its own language levels or (default) inherit them from the workspace settings. Saves having to tailor each project minutely in cases where you don't care. 

 

When you say "source compliance level" and "generated class code level", you're setting the options for the selected JDK to compile with, not selecting the JDK itself (which is a completely different option). 

In other words, you're doing something like "/usr/java/jdk1.6/bin/javac -source 1.4 XXXXFile.java", not switching to JDK 1.4. However, by setting the JDK 1.4 source level, the 1.6 compiler knows, for example, that "enum" is a valid variable name (as it was in JDK 1.4 and earlier) and not a reserved word (JDK 1.5 and later). 

（enum在1.6編譯的時候就報錯，這個例子就是我在項目中碰見的問題）

This is where Java shows that it was designed for Enterprise use. A certain other platform I could mention lacks those options, and if you need legacy support in an emergency, well, tough luck. 

Obviously, it's one thing to be backwards compatible, and another to be prescient, so while you can declare 1.4 compatibility mode on the 1.6 JDK, you can't declare 1.6 compatibility mode on JDK 1.4. 

There's more than just one reason why Eclipse supports multiple JDKs, however. While legacy code occasionally does end up requiring the actual 1.4 compiler rather than 1.6 running in 1.4 mode, you may also have things like 1.6.0_u10 and 1.6.0_u20 JDKs installed at the same time. Say, for example, where there's a project that happens to crash the 1.6.0_u20 VM when you debug it, so you have to fall back to the 1.6.0_u10 version (these aren't necessarily real JVM names, but you get the idea, I hope!).