Java基礎系列1-Java語言概述

文章目錄

• 一.Java發展史
• 二.Java應用平台
• 三.跨平台使用
• 四. JVM JRE JDK
• • 4.1 JDK
  • 4.2 JRE
  • 4.3 JVM
  • 4.4 什麼是JDK源碼? 各廠商JDK版本之間是什麼關系？
• 參考:

一.Java發展史

  1991年4月，由詹姆斯高斯林（James Gosling）博士上司的綠色計劃（Green Project）開始啟動，此計劃最初的目标是開發一種能夠在各種消費性電子産品（如機頂盒、冰箱、收音機等）上運作的程式架構。這個計劃的産品就是Java語言的前身：Oak（得名與James Gosling辦公室外的一棵橡樹）。Oak當時在消費品市場上并不算成功，但随着1995年網際網路潮流的興起，Oak迅速找到了最适合自己發展的市場定位并蛻變成為Java語言。

  1995 年 5 月 23 日，Oak語言改名為Java，并且在SunWorld大會上正式釋出Java 1.0 版本。Java語言第一次提出了“Write Once，Run Anywhere”的口号。

  1996 年 1 月 23 日，JDK 1.0 釋出，Java語言有了第一個正式版本的運作環境。JDK 1.0 提供了一個純解釋執行的Java虛拟機實作（Sun Classic VM）。JDK 1.0 版本的代表技術包括：Java虛拟機、Applet、AWT等。

 

  1996 年 4 月，十個最主要的作業系統和計算機供應商聲明将在産品中嵌入Java技術。同年9月，已有大約8.3萬個網頁應用了Java技術來制作。在1996年5月底，Sun于美國舊金山舉行了首屆JavaOne大會，從此JavaOne成為全世界數百萬Java語言開發者每年一度技術盛會。

 

  1997 年 4 月，Sun公司釋出了 JDK 1.1，Java裡許多最基礎的技術支撐點（如JDBC）等都是在JDK 1.1 版本中提出的，JDK 1.1 版的技術代表有：JAR檔案格式、JDBC、JavaBeans、RMI等。Java語言的文法也有了一定的增強，如内部類（Inner Class）和反射（Reflection）都是在這個時候出現的。

 

  直到1994 年 4 月 8 日，JDK 1.1 一共釋出了 1.1.0 至 1.1.8 這9個版本。從 1.1.4 以後，每個JDK版本都有一個屬于自己的名字（工程代号），分别為：JDK 1.1.4 - Sparkler（報送）、JDK 1.1.5 - Pumpkin（南瓜）、JDK 1.1.6 - Abigial（阿比蓋爾，女子名）、JDK 1.1.7 Brutus（布魯圖，古羅馬政治家和将軍）和 JDK 1.1.8 - Chelsea（切爾西，城市名）。

 

  1998 年 12 月 4 日，JDK迎來了一個裡程碑式的重要版本：工程代号為 Playground（競技場）的 JDK 1.2，Sun在這個版本中把Java技術體系拆分為三個方向，分别是面向桌面應用開發的 J2SE（Java 2 Platform，Standard Edition）、面向企業級開發的 J2EE（Java 2 Platform，Enterprise Edition）和面向手機等移動終端開發的 J2ME（Java 2 Platform，MicroEdition）。在這個版本中出現的代表性技術非常多，如 EJB、Java Plug-in、Java IDL、Swing等，并且這個版本中 Java 虛拟機第一次内置了JIT（Just In Time）即時編譯器（JDK 1.2 中曾并存過三個虛拟機，Classic VM、HotSpot VM 和 Exact VM，其中 Exact VM 隻在 Solaris 平台出現過；後面兩款虛拟機都是内置了 JIT 即時編譯器的，而之前版本所帶的 Classic VM 隻能以外挂的形式使用即時編譯器）。在語言和 API 層面上，Java 添加了 strictfp 關鍵字，Java 類庫添加了現在 Java 編碼之中極為常用的一系列 Collections 集合類等。在 1999 年 3 月和 7 月，分别有 JDK1.2.1 和 JDK 1.2.2 兩個小更新版本釋出。

 

  1999 年 4 月 27 日，HotSpot 虛拟機誕生。HotSpot 最初由一家名為 “Longview Technologies” 的小公司開發，由于 HotSpot 的優異表現，這家公司在 1997 年被 Sun 公司收購。HotSpot 虛拟機剛剛釋出時是作為 JDK 1.2 的附加程式提供的，後來他成為 JDK 1.3 及之後所有 JDK 版本預設的 Java 虛拟機。

 

  2000 年 5 月 8 日，工程代号為 Kestrel（美洲紅隼）的 JDK 1.3 釋出。相對于 JDK 1.2，JDK 1.3 的改進主要展現在 Java 類庫上（如數學運算和新的 Timer API 等），JNDI 服務從 JDK 1.3 開始被作為一項平台級服務提供（以前 JNDI 僅僅是一項擴充服務），使用 CORBAIIOP 來實作 RMI 的通信協定，等等。這個版本還對 Java 2D 做了很多改進，提供了大量新的 Java 2D API，并添加了新的 JavaSound 類庫。 JDK 1.3 有一個修正版本 JDK 1.3.1，工程代号為 Ladybird（瓢蟲），于 2001 年 5 月 17 日釋出。

 

  自從 JDK 1.3 開始，Sun 公司維持着穩定的研發節奏：大約每隔兩年釋出一個 JDK 的主版本，以動物命名，期間釋出的各個修正版本則以昆蟲作為工程代号。

 

  2002 年 2 月 13 日，JDK 1.4 釋出，工程代号為 Merlin（灰背隼）。JDK 1.4 是标志着 Java 真正走向成熟的一個版本，Compaq、Fujitsu、SAS、Symbian、IBM等著名公司都有參與功能規劃、甚至實作自己獨立發行的 JDK 1.4 。哪怕是在近二十年後的今天，仍然有一些主流應用能夠運作在 1.4 上的版本，JDK 1.4 同樣帶來了很多新的技術特性，如正規表達式、異常鍊、NIO、日志類、XML 解析器和 XSLT 轉換器，等等。JDK 1.4 有兩個後續修正版：2002 年 9 月 16 日釋出的工程代号為 Grasshopper（蚱蜢）的 JDK 1.4.1 與 2003 年 6 月 26 日釋出的工程代号為 Mantis（螳螂）的 JDK 1.4.2。

 

  2002 年前後還發生了一件與 Java 沒有直接關系，但事實上對 Java 的發展程序影響很大的事件，就是微軟的 .NET Framework 釋出 。這個無論是技術實作還是目标用于上都與 Java 有很多相近之處的技術平台給 Java 帶來了很多讨論、比較與競争增， .NET 平台和 Java 平台之間聲勢浩大的孰優孰劣的論戰到今天為止都仍沒有完全平息。

 

  2004 年 9 月 23 日，JDK 5 釋出，工程代号為 Tiger（老虎）。Sun 公司從這個版本開始放棄了謙遜的 “JDK 1.x” 的命名方式，将産品版本号修改成了 “JDK x”。從 JDK 1.2 以來，Java在文法層面上的變動一直很小，而 JDK 5 的 Java 文法易用性上做出了非常大的改進。如：自動裝箱、泛型、動态注解、枚舉、可變長參數、周遊循環（foreache循環）等文法特性都是在 JDK 5 中加入的。在虛拟機和 API 層面上，這個版本改進了 Java 的記憶體模型（Java Memory Model，JMM）、提供了 java.util.concurrent 并發包等。另外， JDK 5 是官方聲明可以支援 Windows 9x 作業系統的最後一個 JDK 版本。

JDK x：Java 從 1.5 版本開始，官方在正式文檔與宣傳上已經不再使用類似 “JDK 1.5” 的命名，隻有程式員内部使用的開發版本号（Developer Version，例如 java -version 的輸出）中才繼續沿用 1.5 、1.6、1.7 這樣的版本号，而公開版本号（Product Version）則是改為 JDK 5.0、JDK 6 、JDK 7 的命名方式，JDK 5.0 中的 “.0” 的字尾從 JDK 6 起也被移除掉。
           

  2006 年 12 月 11 日，JDK6 釋出，工程代号為 Mustang（野馬）。在這個版本中，Sun 公司終結了從 JDK 1.2 開始已有八年曆史的 J2EE、J2SE、J2ME 的産品線命名方式，啟動 Java EE 6、Java SE 6、Java ME 6 的新命名來代替。JDK 6 的改進包括：提供初步的動态語言支援（通過内置的 Mozilla JavaSript Rhino 引擎實作）、提供編譯器注解處理器和微型 HTTP 伺服器 API，等等。同時，這個版本對 Java 虛拟機内部做了大量改進，包括鎖與同步、垃圾收集、類加載等方面的實作都有相當多的改動。

 

  在 2006 年 11 月 13 日的 JavaOne 大會上，Sun 公司宣布計劃要把 Java 開源，在随後的一年多時間内，他陸續的将 JDK 的各個部分在 GPL v2（GNU General Public License v2）協定下公開了源碼，并建立了 OpenJDK 組織對這些源碼進行獨立管理。除了極少量的産權代碼（Encumbered Code，這部分代碼所有權不屬于 Sun 公司，Sun本身也無權進行開源處理）外，OpenJDK 幾乎擁有了當時 SunJDK 7 的全部代碼，OpenJDK 的品質主管曾經表示在 JDK 7 中，SunJDK 和 OpenJDK 除了代碼檔案頭的版權注釋之外，代碼幾乎是完全一樣的，是以 OpenJDK 7 與 SunJDK 7 本質上就是同一套代碼庫出來的産品。

 

  JDK 6 釋出以後，由于代碼複雜性的增加、Java 開源、開發 JavaFX、世界經濟危機及 Oracle 對 Sun 的收購案等原因，Sun公司在發展 Java以外的事情上耗費了太多精力和資源， JDK 的更新沒有能夠繼續維持兩年釋出一個主版本的研發速度，這導緻了 JDK 6 的生命周期異常的長，一共釋出了 211 個更新更新更新檔，最後的版本為 Java SE 6 Update 211，于2018 年 10 月 18 日釋出。

 

  2009 年 2 月 19 日，工程代号為 Dolphin（海豚）的 JDK 7 完成了其第一個裡程碑版本。按照 JDK 7 最初的功能規劃，一共會設定十個裡程碑。最後一個裡程碑版本原計劃定于 2010 年 9 月 9 日結束，但由于各種原因， JDK 7 最終無法按計劃完成。

 

  從 JDK 7 最原始的功能清單來看，它本應是一個包含許多重要改進的 JDK 版本，其中規劃的子項目都為 Java 業界翹首以盼，包括：

1. Lambda 項目：支援 Lambda 表達式，支援函數式程式設計。
2. Jigsaw 項目：虛拟機層面的子產品化支援。
3. 動态語言支援：Java 是靜态語言，為其它運作在 Java 虛拟機上的動态語言提供支援。
4. Garbage-First 收集器。
5. Coin 項目：Java文法細節進化。

  令人惋惜的是，在 JDK 7 開發期間，Sun 公司相繼在技術競争和商業競争中陷入泥潭，公司的股票市值跌至僅有高峰時期的 3%，已無力推動 JDK 7 的研發工作按計劃繼續進行。為了盡快結束 JDK 7 長期跳票的問題，Oracle 收購 Sun公司後随即宣布馬上實行 “ B計劃 ”，大幅裁減了 JDK 7 預定目标，以保證 JDK 7 的正式版能夠于 2011 年 7 月 28 日準時釋出。 “ B 計劃 ” 的主要措施是吧不能按時完成的 Lambda 項目、Jigsaw 項目和 Coin 項目的部分改進延遲到 JDK 8 之中。最終， JDK 7 包含的改進有：提供新的 G1 收集器（G1 在釋出時依然處于 Experimental 狀态，直至 2012 年 4 月的 Update 4 中才正式商用）、加強對非 Java 語言的調用支援（JSR-292，這項特性在到 JDK 11 還有改動）、可并行的類加載架構等。

 

  Oracle 公司接手了 JDK 開發工作以後，迅速展現出了完全不同于 Sun 時期的、極具商業化的處事風格。面對 Java 中使用最廣泛而又一直免費的 Java SE 産品線， Oralce 很快定義了一套新的 Java SE Support 産品計劃，把 JDK 的更新支援作為一項商業服務。 JDK 7 釋出的前 80 個更新仍然免費面向所有使用者提供，但後續的其他更新包，使用者隻能從 “将 Java SE 更新到 Java SE Support ” 與 “将 JDK 7 更新到最新版本”兩個選項裡挑一個。 JDK 7 計劃維護至 2022年，迄今（面向付費使用者）已經釋出了超過兩百個更新更新檔，最最新版本為 JDK 7 Update 221。

Java SE Support：除了 Java SE Support 外，還有面向獨立軟體提供商的 Java SE Advanced & Suite 産品線，差别是後者帶有 JMC 等監控工具。詳見《深入了解Java虛拟機》 第三版 第四章 周志明著。
使用者：特指商業使用者，個人實用仍然是可以免費獲得這些更新包的。
           

  對于 JDK 7，還有一點值得提起的是，從 JDK 7 Update 4 起，Java SE 的核心功能正式開始為 Mac OS X 作業系統提供支援，并在 JDK 7 Update 6 中達到所有功能與 Mac OS X 完全相容的程度；同時，JDK 7 Update 6 還對 ARM 指令集架構提供了支援。至此，官方提供的 JDK 可以運作于 Windows（不含 Windows 9x）、Linux、Solaris 和 Mac OS X 作業系統上，支援 ARM、x86、x86-64 和 SPARC 指令集架構，JDK 7 也是可以支援 Windows XP 作業系統的最後一個版本。

最後一個版本：這是官方的聲明，而事實上直到 JDK 8 Update 21 之前在 Windows XP 上仍可正常運作。
           

  2009 年 4 月 20 日，Oralce 宣布正式以 74 億美元的價格收購市值曾超過 2000 億美元的 Sun 公司，傳奇的 Sun Microsystems 從此落幕成為曆史，Java 商标正式劃歸 Oralce 所有（Java 語言本身并不屬于哪間公司所有，他由 JCP 組織進行管理，盡管在 JCP 中 Sun 及後來的 Oracle 的話語權很大）。由于此前 Oralce 已經收購了另外一家大型的中間件企業 EBA 公司，當完成對 Sun 公司的收購之後，Oralce 分别從 BEA 和 Sun 手中取得了世界三大商用虛拟機的其中兩個：JRockit 和 HotSpot。當時 Oracle 宣布要在未來一直兩年的時間内，把這兩個優秀的 Java 虛拟機合二為一（HotRockit）。兩者合并的結果隻能說差強人意，JRockit 的監控工具 Java Mission Control 被移植到了HotSpot，作為收費功能提供給購買了 Java SE Advanced 産品計劃的使用者，其他功能由于兩者架構的差異性明顯，HotSpot 能夠直接借鑒融合的功能寥寥無幾。

HotRockit：“HotRockit” 項目的相關介紹： http://hirt.se/presentations/WhatToExpect.ppt （通路失敗）
寥寥無幾：除了 JMC 和 JFR ，HotSpot 用本地記憶體代替永久代實作方法區，支援本地記憶體使用情況追蹤（NMT）功能是從 JRockit 借鑒過來的。
           

  JDK 8 的第一個正式版本原定于 2013 年 9 月釋出，最終還是跳票導了 2014 年 3 月 18 日，盡管仍然是沒有趕上正點，但比起 JDK 7 那種以年作為計時機關、直接把公司跳崩的研發狀況已是大有改善。為了保證日後 JDK 研發能更順利的進行，從 JDK 8 開始， Oracle 啟用 JEP （JDK Enhancement Proposals）來定義和管理納入新版 JDK 釋出範圍的功能特性。JDK 8 提供了那些曾在 JDK 7 中規劃過，但最終未能在 JDK 7 中完成的功能，主要包括：

1. JEP 126：對 Lambda 表達式的支援，這讓 Java 語言擁有了流暢的函數式表達能力。
2. JEP 104：内置 Nashorn JavaScript 引擎的支援。
3. JEP 150：新的時間、日期 API

4. JEP 122：徹底移除 HotSpot的永久代。

   ……

    

     “B計劃” 中原本說好的會在 JDK 8 提供的 Jigsaw 子產品化功能再次被延期到了 JDK 9，不得不說，即使放到整個 Java 發展史看，Jigsaw 都能算是天字第一号的大坑。Java 的子產品化系統本身面臨的技術挑戰就很艱巨，從微軟的 DLL 技術開始，到 Java 自己的 JAR，再到 .NET 的 Assembly，工程龐大起來都無一例外會陷入 “子產品地獄” 的困境之中，而 Jigsaw 面臨的更大困難是廠商之間以标準話語權為目的，以技術為 “找茬” 手段的激烈競争。

子產品地獄：來自于以前的 “DLL Hell”，如果不清楚什麼是子產品地獄的話，打開計算機的 windows 目錄或者C:\\windows\system32 目錄就明白了。
           

  原本 JDK 9 是計劃在 2016 年釋出的，但在 2016 年伊始，Oralce 就宣布 JDK 9 肯定要延期至 2017 年，後來又連續經過了兩次短時間的跳票，最終到 2017 年 9 月 21 日才得以艱難面世。後兩次跳票的原因是以 IBM 和 RedHat 為首：的十三家企業在 JCP 執行委員會上聯手否決了 Oracle 提出的 Jigsaw 作為 Java 子產品化規範進入 JDK 9 釋出範圍的提案。憑良心說，Java 确實有子產品化的剛需，不論是 JDK 自身（例如拆分出 Java SE Embedded 這樣規模較小的産品）亦或是 Java 應用都需要用到子產品化。這方面 IBM 本身就是各大 Java 發行廠商中做得最好的，它不僅讓自家的 JDK 實作了高度子產品化，還帶頭成立了 OSGi 聯盟，制定了 Java 架構層面子產品化的事實标準，是以它當然會想把 OSGi 推到 Java 規範裡去争個 “名份”，而不是被 Jigsaw 革掉 “性命”。可是 Oracle 對此沒有絲毫退讓，不惜向 JCP 發去公開信，直言如果提案最後無法通過，那 Oracle 将摒棄 JSR 專家組，獨立發展帶 Jigsaw 的 Java 版本，Java 頓時面臨如 Python 2 與 Python 3 那般分裂的危機。

以 IBM 和 RedHat 為首：其實就是以 IBM 為首， IBM 一直與 RedHat 有密切合作，2018 年 IBM 以 340 億美元天價收購了 RedHat 。
JDK 9 釋出範圍的提案：投票記錄：https://jcp.org/en/jsr/results?id=5959
向 JCP 發去公開信：公開信：https://www.infoq.cn/article/2017/05/jigsaw-open-letter
           

  不論如何，經過前後六輪投票，經曆桌上桌下的鬥争與妥協，Java 沒有分裂，JDK 9 總算是待着 Jigsaw 最終釋出了，除了 Jigsaw 外，JDK 9 還增強了若幹工具（JS Shell、JLink、JHSDB等），整頓了 HotSpot 各個子產品各自為戰的日志系統，支援 HTTP 2 用戶端 API 等 91 個 JEP。

 

  JDK 9 釋出後，Oracle随即宣布 Java 将會以持續傳遞的形勢和更加靈活的研發節奏向前推進，以後 JDK 将會在每年的 3 月 9 月各釋出一個大版本，目的就是為避免衆多功能特性被集中捆綁到一個 JDK 版本上而引發傳遞風險。這次改革确實從根源上解決了跳票問題，但也為 Java 的使用者和發行商帶來了頗大的壓力，不程序式員感慨 “Java 新版本還沒開始用就已經過時了”，Oralce 自己對着一堆 JDK 版本分支也在撓頭，不知道如何維護更新，如何提供技術支援。Oracle 的解決方案是順理成章的終結掉 “每個 JDK 版本最少維護三年” 的優良傳統，從此以後，每六個 JDK 大版本中才會被劃出一個長期支援（Long Term Support，LTS）版，隻有 LTS 版的 JDK 能夠獲得為期三年的支援和更新，普通版的 JDK 就隻有短短六個月的生命周期。 JDK 8 和 JDK 11 會是 LTS 版，在下一個就到了 2021 年釋出的 JDK 17 了。

大版本：也該掉了在開發版号中1.7、1.8的命名，從 JDK 10 後将是年份加月份作為開發版本号，比如 18.3 ，即表示 2018年 3 月的大版本。
           

  2018 年 3月 20 日， JDK 10 如期釋出，這版本的主要研發目标是内部重構，諸如統一源倉庫、統一垃圾收集器接口、統一即時編譯器接口（JVMCI 在 JDK 9 已經有了，這裡是引入新的 Graal 即時編譯器）等，這些都将會是對未來 Java 發展大有脾益的改進，但對普通使用者來說 JDK 10 的新特性就顯得乏善可陳，畢竟它隻包含了 12 個 JEP，而且其中隻有本地類型推斷這一個編碼端可見的改進。盡管 JDK 10 可見的改進有限，但 2018 這一年 Java 圈絲毫不缺乏談資，相繼發生了幾件與 “金錢” 相關的曆史性大事件。

 

  首先是 2018 年 3 月 27 日，Android 的 Java 侵權案有了最終判決，法庭裁定 Google 賠償 Oracle 合計 88 億美元，要知道 2009 年 Oralce 收購 Sun 也就隻花了 74 億，收購完成後随機就用 Sun 的專利把 Google 告上了法庭，經過 Oralce 法務部的幾輪神操作，一場官司的賠償讓收購 Sun 公司等同于免費。對此事 Java 技術圈多數吃瓜群衆是站在 Google 這邊的，認為 Oralce 這樣做是自絕 Java 的發展前景，畢竟當年 Android 剛剛起步的時候可以 Sun 公司向 Google 抛去的橄榄枝，Android 的流行也鞏固了 Java “第一程式設計語言” 的行業地位。摒棄對企業好惡情感，就事論事，Google 采用 Java 的文法和 API 類庫，開發出來的程式卻不能運作在其他 Java 虛拟機之上，這事情無論怎樣都是有違 Java 技術的精神原旨的，也肯定違反了 Java 的使用協定。如果說 Oralce 控告 Google “不厚道”，那當年微軟用 J++ 做了同樣的事情（借用文法和 API，但程式不相容标準 Java 虛拟機），被 Sun 告到登報道歉，一邊賠款一遍割地，聲明放棄 J++ 語言和 Windows 平台上的内置虛拟機，這又該找誰說理去？

使用協定：Oralce 與 Google 的官司主要焦點在于 Java API 的版權問題，而不在程式是程式能否運作在标準 Java 虛拟機上。
           

  按常理說 Java 剛給 Oralce 賺了 88 億美金，該頗為受寵才對，可 Oralce 是典型之談利益不講情懷的公司，InfoWorld 披露了一封 Oralce 高管郵件表明，Java 體系中被認為無法盈利也沒有太多戰略前景的部分會逐漸被 “按計劃報廢”（Planned Obsolescence）。這事的第一刀落下是在 2018 年 3 月，Oralce 正式宣告 Java EE 成為曆史名詞。雖然 Java SE、Java EE 和 Java ME 三條産品線裡确實隻有 Java SE 稱得上成功，但 Java EE畢竟無比輝煌過，現在還持有着 JDBC、JMS、Servlet 等使用極為廣泛的基礎元件，然而 Oracle 仍選擇把他們 “掃地出門”，所有權直接贈送給 Eclipse 基金會，唯一的條件是以後不準再使用 “Java” 這個商标，是以取而代之的将是 Jakarta EE 。

InfoWorld 披露了一封 Oralce 高管郵件表明：資料來源： https://www.infoworld.com/article/2987529/insider-oracle-lost-interest-in-java.html
以後不準再使用 “Java” 這個商标：最大的争議點是 Oralce 要求包名中不能出現 java 字樣，導緻一堆 javax.* 開頭的包一旦修改或者添加新代碼，就必須重新命名，這将讓用到它們的代碼都收到影響。資料來源：https://www.infoq.cn/article/2018/02/from-javaee-to-jakartaee 。
           

  2018 年 10 月，JavaOne 2018 在舊金山舉行，此前沒有人想到過這會是最後一屆 JavaOne 大會，這個在 1996 年伴随着 Java 一同誕生、成長的開發者年度盛會，竟是 Oralce 下一個裁撤的對象，此外還有 Java Mission Control 的開發團隊，也在2018 年 6 月被 Oralce 解散。

裁撤的對象：Java One 大會從 2019 年起停辦，合并入 Oralce CodeOne 大會中。
           

  2018 年 9 月 25 日，JDK 11 釋出，這是一個 LTS 版本的 JDK ， 包含 17 個 JEP，其中 ZGC 這樣的革命性的垃圾收集器出現，也有把 JDK 10 中的類型推斷加入 Lambda 文法這種可見的改進，但都比不過他釋出時爆發出來的謠言轟動：“Java 要開始收費啦！”

 

  随着 JDK 11釋出，Oralce同時調整了 JDK 的授權許可證，裡面包含了好幾個動作。首先，Oralce 從 JDK 11起把以前的商業特性全部開源給 OpenJDK，這樣 OpenJDK 11 和 OralceJDK 11 的代碼和功能，在本質上就是完全相同的（官方原文是 官方原文是 Essentially Identicial）。然後，Oralce 宣布以後将會同時發行兩個 JDK：一個是以 GPLv2+CE 協定下由 ORALCE 發行的傳統 OpenJDK（後面将稱為Oralce OpenJDK），另一個是在新的 OTN 寫一下發行的傳統的 OralceJDK，這兩個 JDK 共享絕大部分源碼，在功能上幾乎是一樣的，核心差異是前者可以免費在開發、測試或生産環境中使用，但是隻有半年時間的更新支援；後者個人依然可以免費使用，但若在生産環境中商用就必須付費，可以有三年時間的更新支援。如果說有由此能得出“Java 要收費” 的結論，那是純屬标題黨，最多隻能說 Oralce 在迫使商業使用者要麼不斷更新 JDK 的版本，要麼就去購買商業特性。

商業特性：需要使用 +XX:+UnilockCommercialFeatures 解鎖的新特性，包括 JMC、JFR、NMT、AppCDS 和 ZGC 等。
Essentially Identicial：資料來源：https://blogs.oracle.com/java-platform-group/oracle-jdk-releases-for-java-11-and-later
在功能上幾乎是一樣的：JDK 11 中僅有的微小差别是 OpenJDK少了幾個 Module（如JavaFX），且不提供安裝包，以壓縮包形式發行。但在 JDK 12 又産生了新的分歧，OpenJDK 的 Shenandoah 垃圾收集器被排除在 OracleJDK 之外，詳見《深入了解Java虛拟機》 第三版 第四章 周志明著。
商業支援：這裡的商業支援不限定于 Oralce 公司，如 Azul ZingJDK、AdoptOpenJDK 等都能提供商業支援。
           

  2019 年 2月，在 JDK 12 釋出前夕，Oralce 果然如之前宣布那樣在六個月之後就放棄了對上一個版本OpenJDK 的維護，RedHat 同時從 Oralce 手上接過 OpenJDK 8 和 OpenJDK 11 的管理權力和維護職責。Oralce 不願意在舊版本上繼續耗費資源，而 RedHat 或者說他背後的 IBM 又樂意擴大自己在 Java 社群的影響力，這是一筆雙赢的交易。RedHat 代替 Oracle 成為 JDK 曆史版本的維護者，應該有利于 Java 的持續穩定，但從技術發展角度來看，這并不能為 Oralce 上司 Java 社群的局面帶來根本性的改變，畢竟要添加新的或實驗性的功能，僅會針對 Java 的最新版本，而不會在舊版本上動手。

維護職責：Red Hat 此前已經是 OpenJDK 6（自 2013 年起）和 OpenJDK 7 （自 2015 年起）的維護者。
           

  2019 年 3月 20 日，JDK 12 釋出，隻包含 8 個 JEP ，其中，主要有 Swtich 表達式、Java微測試套件（JMH）等新功能，最引人注目的特性無疑是加入了由 RedHat 上司開發的 Shenandoah 垃圾收集器。Shenandoah 作為首個非 Oralce 開發的垃圾收集器，其目标又與 Oralce 在 JDK 11 中釋出的 ZGC 幾乎完全一緻，兩者天生就存在競争。Oralce 馬上用實際行動抵制了這個新收集器，在 JDK 11 釋出時才說應盡可能保證 OralceJDK 和 OpenJDK 的相容一緻，轉眼就在 OralceJDK 12 裡把 Shenandoah 的代碼通過條件編譯強行剔除掉，使其成為曆史上唯一進入了 OpenJDK 釋出清單，但在 OralceJDK 中無法使用的功能。

 

  Oracle 收購 Sun 是 Java 發展曆史上一道明顯的分界線。在 Sun 掌舵的前十幾年裡，Java 獲得巨大成功，同時也漸漸顯露出來語言演進的緩慢與社群決策的老朽；而在 Oracle 主導 Java 後，因其競争的同時也帶來新的活力，Java 發展的速度要顯著高于 Sun 時代。Java 的未來是繼續向前、再攀高峰，還是由盛轉衰、鋒芒挫縮，你我拭目以待。

 

  Java 面臨的危機挑戰前所未有的艱巨，屬于 Java 的未來也從未如此充滿想象與可能。

二.Java應用平台

Java SE 标準版：支援桌面級應用（如Windows下的應用程式）的Java平台，提供了完整的Java核心API，這條産品線在JDK6以前被稱為J2SE。

Java ME 小型版：支援Java程式運作在移動終端（手機、PDA）上的平台，對Java API有所精簡，并加入了移動端的針對性支援，這條産品線在JDK6以前被稱為J2ME。注意，現在智能手機上非常流行的、主要是用Java語言開發程式的Android并不屬于Java ME。

Java EE 企業版：支援使用多層架構的企業級應用（如ERP、MIS、CRM應用）的Java平台，除了提供Java SE API外，還對其作了大量有針對性的擴充，并提供了相關的部署支援，這條産品線在JDK 6以前被稱為J2EE，在JDK 10以後被Oracle放棄，捐獻給Eclipse基金會管理，此後被稱為Jakarta EE。

擴充：這些擴充一半一半 javax.* 作為包名，而以 java.*為包名的包都是 Java SE API 的核心包，但由于曆史原因，一部分曾經是擴充包的 API 後來進入了核心包中，是以核心包中也包含了不少 javax.* 開頭的包名。
           

三.跨平台使用

平台：指的是作業系統(Windows，Linux，Mac)

跨平台：Java程式可以在任意作業系統上運作，一次編寫到處運作

原理：java通過javac将源檔案編譯為.class檔案（位元組碼檔案），該位元組碼檔案遵循了JVM（Java Virtual Machine）的規範，使其可以在不同系統的JVM下運作。

過程：java 編譯過程：java源程式（.java）->java編譯器（javac.exe）->位元組碼檔案(.class)->java解釋器（java.exe)->作業系統

四. JVM JRE JDK

為什麼JDK中包含一個JRE?

開發完的程式，需要運作一下看看效果。

JDK,JRE,JVM的作用和關系：

1. JDK包含JRE 和開發工具包
2. JRE 包含 核心類庫和JVM

4.1 JDK

JDK是提供給Java開發人員使用的，java開發工具包，是sun公司提供的一套用于開發java應用程式的開發包，它提供了編譯、運作java程式所需的各種工具和資源，包括java編譯器、java運作時環境，以及常用的java類庫等。

JDK中包含了java的開發工具，也包括了JRE。是以安裝了JDK，就不用在單獨安裝JRE了。

其中的開發工具：編譯工具(javac.exe) 打包工具(jar.exe)等

JKD = Java程式語言 + JRE

4.2 JRE

包括Java虛拟機(JVM Java Virtual Machine)和Java程式所需的核心類庫等。JRE是支援Java程式運作的标準環境，用于解釋執行Java的位元組碼檔案。普通使用者而隻需要安裝 JRE 來運作 Java 程式。而程式開發者必須安裝JDK來編譯、調試程式。

JRE = Java虛拟機（JVM）+ Java類庫API中的JavaSE API子集

4.3 JVM

JVM是java虛拟機(JVM Java Virtual Machine)，是JRE的一部分。負責解釋執行位元組碼檔案，是可運作java位元組碼檔案（.class檔案）的虛拟計算機。

4.4 什麼是JDK源碼? 各廠商JDK版本之間是什麼關系？

  OpenJDK是 Sun 公司在 2006 年末把 Java 開源而形成的項目，這裡的“開源”是通常意義上的源碼開放形式，即源碼是可被複用的，例如 OracleJDK、Oralce OpenJDK、AdoptOpenJDK、Azul Zulu、SAP SapMachine、Amazon Corretto、IcedTea、UltraViolet 等都是從 OpenJDK源碼衍生出的發行版。但如果僅從 “開源” 的字面有意義（可開放閱讀的源碼）上講的話，其實 Sun 公司自 JDK 5 時代起就曾經以 JRL （Java Research License）的形式公開過 Java 的源碼，主要是開放給研究人員閱讀使用，這種 JRL 許可證的開放源碼一直持續到 JDK 6 Update 23 才因 OpenJDK 項目日漸成熟而終止了如果拿 OpenJDK 中的源碼跟對應版本的 JRL 許可證時性開放的 Sun/OracleJDK 源碼互相比較的話，會發現除了檔案頭的版權注釋外，其餘代碼幾乎都是相同的，隻有少量設計引用第三方的代碼存在差異，如字型栅格化渲染，這部分内容 OralceJDK 采用了商業實作，源碼版權不屬于 Oracle 自己，是以也無權開源，而 OpenJDK 中使用的是同樣開源的 FreeType 代替。

 

  當然，“代碼相同” 必須建立在兩者共有的組建基礎之上，OpenJDK 中的源碼倉庫隻包含了标準 Java SE 的源代碼，而一些額外的子產品，典型的如 JavaFX ，雖然後來也被 Oracle 開源并放到 OpenJDK 組織進行管理 （OpenJFX項目），但是他是存放在獨立的源碼倉庫中，是以 OralcJDK 的安裝包中會包含 JavaFX 這種獨立的子產品，而用 OpenJDK 的話則需要單獨下載下傳安裝。

 

  此外，在 JDK 11 以前，OralceJDK 中的源碼倉庫隻包含了标準 Java SE 的源代碼，而一些額外的子產品，典型的如 JavaFX ，雖然後來也是被 Oracle 開源并放到 OpenJDK 組織進行管理（OpenJFX項目），但是它是存放在獨立的源碼倉庫中，是以 OralceJDK 的安裝包中會包含 JavaFX 這種獨立的子產品，而用 OpenJDK 的話則需要單獨下載下傳安裝。

 

  此外，在JDK 11 以前，OralceJDK 中還存在一些 OpenJDK 沒有的、閉源的功能，即 OracleJDK 的 “商業特性” 。例如 JDK 8 起從 JRockit 移至改造而來的 Java Flight Recorder 和 Java Mission Control 元件、JDK 10 中的應用類型共享功能（AppCDS） 和 JDK 11 中的 ZGC 收集器，這些功能在 JDK 11 時才全部開源導了 OpenJDK 中。到了這個階段，我們已經可以認為 OpenJDK 與 OralceJDK 代碼實質上已經達到完全一緻的程度。

實質上：嚴格來說，這裡 “實質上” 可以了解為除去一些版權資訊（如 java -version 的輸出）、除去針對 Oralce 自身特殊硬體平台的适配、除去 JDK 12 中 OralceJDK 排除了 Shenandoah 這類特意設定的差異之外是一緻的。
           

  根據 Oralce 的項目釋出經理 Joe Darcy 在 OSCON 大會上對兩者關系的介紹也證明了 OpenJDK 和 OralceJDK 在程式上是非常接近的，兩者共用了絕大部分相同的代碼（如圖 1-7 所示。注意圖中的英文提示了兩者共同代碼的占比要遠高于圖形上看到的比例），是以我們自己編譯的 OpenJDK，基本上可以認為性能、功能和執行邏輯上都和官方的 OracleJDK 是一緻的。

  下面再來看一下 OpenJDK 内部不同版本之間的關系，在 OpenJDK 接收 Sun 公司移交的 JDK 源碼時，Java 正處于 JDK 6 時代的初期，JDK 6 Update 1 才剛剛釋出不久，JDK 7 則完全是處于研發狀态的半成品。OpenJDK 的第一個版本就是來自于當時 Sun 公司正在開發的 JDK 7，考慮到 OpenJDK 7 的狀況在當時完全不足以支援實際的生産部署，是以又在 OpenJDK 7 Build 22 的基礎上建立了一條新的 OpenJDK 6 分支，剝離掉所有 JDK 8 新功能的代碼，形成一個可以通過 TCK 6 測試的獨立分支，先把 OpenJDK 6 釋出出去給公衆使用。等到OpenJDK 7 達到了可正式對外釋出的狀态之後，就從 OpenJDK 7 的主分支延伸出用于研發下一代 Java 版本的 OpenJDK 8 以及用于釋出更新更新檔的 OpenJDK 7 Update 兩條子分支，按照開發習慣，新的功能或 Bug 修複通常是在最新分支上進行的，當功能或修複在最新分支上穩定之後會同步到其他老版本的維護分支上。後續的 JDK 8 和 JDK 9 都重複延續着類似的研發流程。通過圖 1-8 （依然是從 Joe Darcy 的 OSCON 示範稿截圖的圖檔）可以比較清楚的了解不同版本分支之間的關系。

 

  到了 JDK 10 及以後的版本，在組織上出現了一些新變化，此時全部開發工作統一歸到 JDK 和 JDK Updates 兩條分支主線上，主分支不再帶版本号，在内部再用子分支來區分具體的 JDK 版本。OpenJDK 不同版本的源碼都可以在它們的首頁（http://openjdk.java.net/）上找到。

參考:

1. https://blog.csdn.net/qq_43529621/article/details/112935996