Java基础系列1-Java语言概述

た入场券 2022-09-01 08:53 221阅读 0赞

### 文章目录 ###

*  一.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语言。

![image.png][]

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)->操作系统

![image.png][image.png 1]

![image.png][image.png 2]

# 四. JVM JRE JDK #

为什么JDK中包含一个JRE?  
开发完的程序，需要运行一下看看效果。

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

1.  JDK包含JRE 和开发工具包
2.  JRE 包含 核心类库和JVM

![image.png][image.png 3]

![image.png][image.png 4]

## 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

[image.png]: /images/20220829/80eaec9caea0421ca314bca572ea93bc.png
[image.png 1]: /images/20220829/84f9015b94d84dfc9eff4e73a7445787.png
[image.png 2]: /images/20220829/a8f11c629f074c8e86f46d2efc126fbd.png
[image.png 3]: /images/20220829/11da5b766ee94c599547c56ed357914e.png
[image.png 4]: /images/20220829/c47a67f23ceb498fa41605710267f031.png