jdk最高編譯器16
公司中一般用myeclipse8.5.很專業的一個軟體。方便
⑵ 最權威用的最廣泛的JAVA編譯器是什麼
JAVA編譯器是JBudler Eclipse ？？
開玩笑！
首先，JBudler Eclipse 屬於IDE，是集成開發環境（IDE）！IDE是集成了編譯，檢錯，自動查找錯誤，深度反檢查功能的輔助開發工具。就是說，只要屬於java的IDE，都會把sun的編譯器集成到它裡面來。而JBudler與Eclipse 等這些開發工具更多的是體現在對不同層面java開發提供了不同的強大功能。比如：MyEclipse強勢在web開發的便捷。JBudler對GUI更強大。
編譯器是java語言轉換為。class的工具，只有sun才是權威的，它把它集成在jdk裡面，如果要單獨使用它，可以從jdk文件重拿出來，或者從sun的網站上下載。
樓主的問題本身問的就有問題：sun的編譯器只有一個，而且是開源的。
你無論用什麼IDE，最終都是用的sun的編譯器編譯源碼的。就是手動編譯用的口令javac。
⑶ jdk中的編譯器是什麼,解釋器是什麼
編譯器是指java程序運行時對java代碼進行語法檢查和代碼規范的一種機制，若不符合代碼規范和語法有錯誤編譯器將會報錯，代碼將無法運行。解釋器我很少聽說，是不是編譯器報錯的時候出現的錯誤提示？
⑷ 把Eclipse的JDK編譯器怎麼選成JDK6
Eclipse選擇JDK6的步驟：
1.點擊進入eclipse編輯器界面，在上方有一個windows的菜單，點擊選擇最下面的preferces，截圖如下：
⑸ java編譯器jdk怎麼用 為什麼我JDK編譯器按照步驟安裝好了以後結果去測試不起呢
va分編譯器和運行環境，我們的系統里自帶了運行環境，可以運行別人編譯好的XXX.class程序，但不能編譯xxx.java。出現你說的情況有兩種可能，一是沒裝java編譯器，二是沒有修改系統環境變數。
先網路個編譯器來，裝上，修改環境變數。樓上的說的太多了，裝上後，如下操作：
「我的電腦>右擊>屬性>高級>環境變數>系統變數」
新建以下三個值：
JAVA_HOME:這是你的jdk所安裝的目錄，值就是你的安裝目錄，我的是E:\jdk
path:這是系統尋找javac時所要查找的路徑所在，javac的位置在bin下。我的是E:\jdk\bin;
classpath:這是類文件存放的位置，這其中要包含java自帶的，所以它可以有以下三部分組成 E:\jdk\lib\tools.jar;E:\javawork\lesson1;.(注意這個點，它是在當前目錄下查詢，不要丟了）
打開cmd，輸入javac,出來一堆調試信息，OK,你成功了！
至於學習方案，建議直接開始《java核心技術》有兩卷，或者《java how to program》兩本不錯的書，基礎一定要打牢，等有了基礎，看下《Thinking in Java》。
等這些ok了，去java開源網站看看，裡面很多世界各地優秀程序員的作品，看看他們的代碼和程序，模仿和學習！
⑹ Unsupported major.minor version 51.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 中 .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 文件處理一下就行了
⑺ jdk是jdk 編譯器是編譯器
jdk是java運行的環境，也是自帶編譯器的，嚴格來說他們的確可以說是不一樣的，但java代碼必須通過編譯器編譯成機器語言才能運行。所以其實我們作為java的使用者來說，認為編譯器是jdk的一部分
而你看到的貼子的，我感覺更像是因為某人的ide(如eclipse)之類的運行不了java代碼，所以另一個人告訴他eclipse的 編譯器設置 錯了
不要誤解了
⑻ java jdk與編譯器有什麼關系
我來說說我的理解吧，你的這種問題一般沒有什麼明確的回答。
java：java是一種編程語言，比如說我用java開發這個項目，普遍的意思就是說用符合java語言的語法的代碼，用java版的編譯器，用的庫是java的庫，不是其他語言的庫。等等，是一個很廣泛的概念。
而jdk：全稱叫做java 開發包，就是說一般java開發的時候所需要的工具，舉個例子，你運行一個java程序的時候，需要 用到編譯器嗎？不需要，但是你開發java應用程序的時候，需要用到編譯器嗎？需要！所以jdk，只要是滿足java開發所需要的東西，都屬於jdk一部分。
而編譯器：編譯器有很多種，一般來說，是將源代碼經過一系列復雜處理，轉換成一定環境的目標文件，為啥說是目標文件而不是說位元組碼文件呢，主要是為了說的更加准確一點，當然，有些時候稱為可執行文件。具體內容，可以參考《程序員的自我修養》。
一般來說，java編譯器屬於jdk一部分，而jdk不一定屬於java語言的一部分，為啥呢？因為jdk包含很多東西，這些東西嚴格來說是屬於C語言或者是C++的一部分。
⑼ 為什麼我安裝了jdk1.7，但是eclipse的屬性里的Java>>Compiler裡面最高只能選到1.6
eclipse的版本限制，你換一個高版本的eclipse就可以了。