Java 之父 James Gosling 最新访谈：JIT 很好，但不适合所有语言
Posted 东海陈光剑
tags:
篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了Java 之父 James Gosling 最新访谈：JIT 很好，但不适合所有语言相关的知识，希望对你有一定的参考价值。
计算机编程确实是一门艺术。
James Gosling，“Java 之父”, 完成了 Java 的原始设计，并实现了 Java 最初版本的编译器和虚拟机。
90年代初，James Gosling和一群技术人员合作“绿色计划”，创建了一个名为Oak的项目，旨在开发出能够运行于虚拟机的编程语言，开创计算机在家电产品上的嵌入式应用。后来，这项工作就演变为Java。
1996年1月，Sun公司发布了Java的第一个开发工具包；
1997年2月，JDK 1.1面世；
1998年12月8日，第二代Java平台的企业版J2EE发布；
2000年5月，JDK1.3、JDK1.4和J2SE1.3相继发布;
.......
(详细版本历史,参看本文后面的附录2部分.)
随着互联网的普及，Java成为全球最流行的开发语言。James Gosling也因此被称作“Java之父”。
James Gosling 在此次访谈中聊了大量关于编程语言的话题，例如对现代编程语言新特性的看法、怎么看待编程语言更新后引起的破坏性变更、为什么不是所有编程语言都使用 JIT 技术等。
Evrone 是一家企业软件开发公司，旗下担任技术布道师 (DevRel) 的 Grigory Petrov 最近对 James Gosling 进行了采访。
James Gosling 在此次访谈中聊了大量关于编程语言的话题，例如对现代编程语言新特性的看法、怎么看待编程语言更新后引起的破坏性变更、为什么不是所有编程语言都使用 JIT 技术等。
在采访中，James提出了许多观点，他认为：“对软件的可靠性要求越高，静态类型语言就越有帮助。”他还分享了自己对某些编程语言的看法：反感C语言中的宏、对Lombok又爱又恨、很喜爱Lisp等等。
关于现代编程语言的构建方式
Grigory：作为软件开发人员和软件顾问，我们试图在俄罗斯组织Python、Ruby、Java和Go社区。您在Java方面的经验和工作可以很好地帮助开发人员。通过这次采访，我们希望能够帮助到其他开发者，一起解决业内的基本问题。
有些语言，比如Go，没有类和继承一说，而另一些语言则尝试使用诸如Rust的特性。作为一名语言设计师，您认为现代通用的、合理的编程语言构建方式应该是什么？
James：我应该会继续使用类，类对我的编程工作很有用。在C语言中有一些宏，这非常糟糕，因为宏不是语言的一部分，不应该纳入其中。而Rust的工作人员正在尝试恰到好处地使用宏。
对于其他语言，如Lisp家族，人们总是设法更灵活地应用它们。它们有一种定义语法的方法，语法几乎完全与语义无关。在大多数语言中，语法和语义是密切相关的。我曾写了很多Lisp，我真的很喜欢使用Lisp程序。有的语言能让你以不同的方式做到这一点，比如在Groovy中，你可以直接使用AST，Rust有一些语法集成的宏。但我总觉得还有一个问题：除此之外还能做什么呢？
Lisp对代码片段进行运算，再生成新代码，在Java世界里，人们就是这样做的。虽然看似低级，但很受欢迎。人们可以使用注释的组合，用一些不同的语言生成字节码，这是超级强大的。它会给你意想不到的惊喜，比如在Jackson，它通过计算序列化程序延展了性能。
一方面，这是一种非常强大的技术，另一方面，它非常难以驾驭。这个技术充满可能性，但这种可能性是有限的。我对Lombok又爱又恨，因为它添加了一大堆Java特性，这些特性都很不错，但从另一方面来说，也显示出了弱点。JCP的社区职能在下降，我已经离开好几年了，虽然有些事情可以做，但也只能是在纸上谈谈。
Grigory：这就是为什么我们更想了解您创建语言的经验，而不是一些Java增强建议。五年前，我尝试操控一些Java字节码。我发现，用它来创建特定领域的语言有点困难。但是有了Ruby后，就容易多了。Evrone公司有许多精通Ruby的开发人员。Ruby开发人员很优秀，但是他们需要多年的培训才能真正掌控DSL的魔力。
James：像代码片段运算这样的特性，在Java中之所以尴尬是因为Java总是试图去编译机器代码，Ruby几乎总是被解释。如果你想同时获得超强功能和终极性能，这一切就会变得很困难。
如何看待那些破坏性的更改？
Grigory：最近，我们采访了Ruby的创作者Yukihiro Matsumoto，他对最新的Ruby 3.0版本进行了实验，试图在不破坏更改的情况下发布这个版本。我知道Java对“不破坏更改”的态度一直很谨慎。让所有语言在完全兼容的情况下进化，这是合理的吗？还是说这个方法只能用于特定的语言，例如Ruby或Java？
James：这几乎完全取决于开发人员社区的规模。每一个破坏性的变更都会给开发人员社区带来痛苦。如果你没有很多的开发人员，那么破坏更改并不是一个大问题。
除此之外，你还必须权衡成本效益。如果你做了一个突破性的改变，它会增加你的工作负担，但也可能会带来一些好处。不过，如果你只是将下标操作符从方括号更改为圆括号，这并不会带来任何好处，只会徒增麻烦。
在JDK 9中，出现了一个罕见的破坏性变化：如果你使用的是隐藏API，封装机制就会被打乱。人们打破封装界限，运用了非常规的方式，使用了不应该使用的东西，这种改变是痛苦的。然而，一旦我们彻底改变，平台便有了更多的创新空间。在这种改变下，平台可以被分割，你可以定制打包，Java的运行环境就会更小。
另一个麻烦是：当遇到Bug时，人们会为之做一些变通措施，如果你修复了这个Bug，变通措施就被破坏了。在Java的世界中，确实有这样的例子，我们要么不修复Bug，要么引入一个方法来修正错误，这甚至体现在硬件上。
如何看待静态类型检查器？
Grigory：25年前，当我开始自己的软件开发生涯时，我写了很多C和C++代码。几乎每个月都会遇到一次错误警报。调试这些错误是一件很痛苦的事情。但是现在，我看到许多工具集成到我们的工作流程中，比如静态类型检查器。现代开发人员使用IDE，如NetBeans、IntelliJ IDEA，甚至Visual Studio。他们编写源代码，编写静态类型检查器解析程序，构造抽象语法树，并进行检查，然后在文本编辑器中标记错误。这些技巧不仅适用于静态类型的语言，也适用于动态类型的语言，在Python、Ruby和TypeScript中皆可使用。
你对静态类型检查器有什么看法？它们能帮助人们编写出更好的程序，还是说需要在语言语法中添加更多内容？
James：我都同意。我非常喜欢使用静态类型系统的语言，因为它们为静态类型检查器和IDE提供了一个框架。作为一名资深软件工程师，寻找那些奇怪的Bug是最浪费时间的。为减少这方面的时间浪费，我会尽力阻止Bug的出现。因此，我非常喜欢IDE，它能够提供减少Bug的方法。而动态类型语言很少有框架来解决这个问题，因为它们不一定能判断所有类型，只能靠猜测。强类型语言（如Java）为类型检查器提供了更严格的框架。在另一个层次上，甚至可以进行自动的定理证明。像Dafny这样的系统，它有一个非常复杂的定理证明器。所以如果你想建立一个加密算法，你将能够用数学方法进行证明。这听上去很夸张，但对于某些代码来说，真的很有用。
这很大程度上取决于你的目标是什么。
如果你是一名正在努力完成作业的大学生，或是一名正在努力毕业的博士生，那么当你编写一个程序时，你的目标是让这个程序至少能运行一次，因为你必须要展示成果。
如果你在行业环境中，那么每次运行都必须成功。一次运行成功和每次都运行成功之间的差别是巨大的。如果只需要运作一次，那么动态语言会更合适。如果你必须确保它能一次又一次地运行，那么所有的静态类型工具都适用。
如果你是一个物理学家，你想得出一些计算结果，那么它只需要运行一次。这取决于你的工作背景。你对软件的可靠性要求越高，静态类型语言就越有帮助。
现在是开源软件的黄金时代吗？
Grigory：我们来谈谈企业和产业发展吧。我从来没做过机器人，但我曾在大型开发公司工作过，如果将今天和20-25年前进行比较，我们会发现，像GitHub这样的社交编码平台，得到了大公司的支持，他们帮助个人开发者和企业软件开发者进行开源开发。那么，现在是不是开源软件的黄金时代呢？你有何看法？
James：我不知道。这个问题涉及未来。“现在是黄金时代吗？”背后的意思是，将来要开始走下坡路了吗？如果现在是黄金时代，那么未来就不是黄金时代了吗？
我认为我们一直都在迈向黄金时代，依然在不断改进。目前，我们依然有各种各样的安全问题，网络攻击不断，因此我不保证这是黄金时代。如果有一种方式，可以终结网络安全隐患，那将是非常好的。现在确实是个好时机，但还可以更好。
为什么有的语言不使用JIT？
Grigory：您使用JIT（即时编译）创建了Java和JVM。JIT保证了高速，同时保持了高级语法。许多语言都跟随你的脚步，比如C#和javascript。其他语言，如Python、Ruby、php，都有可选的JIT，但不太常用。许多主流语言也并不使用JIT来提升速度。为什么不是所有的语言都使用JIT呢？他们不想为软件开发人员提供更快的速度吗?
James：如果开发者想要获得性能改进，那么使用静态类型语言是非常有用的。通常，人们会给语言添加注释，就会得到TypeScript这样的语言，TypeScript的本质就是带有类型注释的JavaScript。而JavaScript的本质是Java，只是去掉了类型声明。所以TypeScript本质上就是带有置换语法的Java。
在Python之类的语言中，通常只有一种数值，那就是双精度浮点数。没有真正的整数，没有字节和16位整数这些东西。如果是双精度浮点数和单精度浮点数，概念认知的过程会很复杂，但你必须掌握数值分析。许多软件工程师对数值分析几乎一无所知，所以他们直接放弃了。
如果你是一个使用Python的物理学家，那么精确度对你来说是最重要的。如果你需要在内存中放入一个非常大的数组，在这种情况下，单精度和双精度或8位整数之间的差异就非常重要。
在我的一生中，我参加过许多数值分析课程，被数值分析弄得焦头烂额，因此我不得不关注数值分析。具体问题具体分析，大多数使用脚本语言的人并不关注这类问题。很多人并不关心具体的性能和数值，他们关心的是：“它够快吗？”性能是一个boolean值，对一些人来说，这更像是调试一辆赛车，如果你的车每小时能够行驶两到三英里，你更有可能获胜。
Grigory：几个月前，Ruby on Rails(一种广受欢迎的Web框架)的作者David Heinemeier Hansson提到，在他的云计算的应用开发中，性能基本都是由缓存、消息队列、存储等方面决定的，开发语言的影响最多不超过15%。他指出，不管Ruby有多“慢”，这都不是很重要，因为即使Ruby的速度快了100倍，将15%变成了1%，也不会改变什么。
James：要具体分析你的任务类型。如果你的任务是由网络和数据库等主导的，你一直在做RPC，那么第一步就是质疑这些RPC是否有价值。微服务确实挺不错，但是它们比方法调用慢一百万倍。想想这意味着什么。
对于大多数人来说，他们可以通过清晰的大规模架构来获得更多性能。但对大部分人而言，所有的细节都很重要。如果你知道高并发的重要性，知道它能够同时驱动数千个进程，进行大型计算；如果你做的是数据库或存储服务，你会非常在意这些细节。所以这完全取决于你手头的任务。
关于现代async/await方法
Grigory：许多语言都采用了协程和async/await方法来处理网速慢之类的问题。这个方法被添加到Python、 Ruby、 JavaScript以及其他语言中。但是在一个线程中这个方法并不是无所不能的，并且很复杂，有时还会使软件运行速度变慢。那么，您如何看待这种现代async/await方法呢？这是处理网络的好方法，还是我们误用了它，我们需要寻找其他方法？
James：这依然取决于实际情况。协程是完美的，它起源于60年代。第一种使用协程的语言是Simula 67。Simula是一种很好的语言，它没有线程，但是有协程，只不过它们做协程的方式看起来很像线程。协程完全避开了并行中的一些难题。对我来说，协程有一个问题：它们不允许使用多个处理器，无法做到真正的并行。因此我已经很久没有使用协程。
所以人们更重视那些真正具有并行性的语言，比如Erlang和Java。
在Java中使用ConcurrentHashMap可以做到很多事情。如果你在进行多协程操作又没有足够的处理器，一旦你使用基于协程的语言并使用多个处理器，最后也只是饱和了一个处理器而已。使用多个处理器也是不得已的，毕竟世界上已经没有单位处理器了。每样东西都有很多内核，如果你想在一个问题上同时使用所有的计算机，你只需要克服多线程所固有的复杂性。
还有样式的问题。透明的控制反转时常发生，而你只能被动接受。这会让你的语法看起来很像线程，但也意味着在真正的线程中会遇到一些问题。例如，你输入“a=a + 1”的语句，你知道这个操作不会被中断，所以你不需要同步。但在其他情况下，它变成了一个event导向的样式，操作过程中，你需要插入一个事件处理程序，去处理后续问题。这就是JavaScript的主要风格。这样也不错，但似乎有点笨拙。
70年代早期，我第一次接触Simula，我发现它很灵活，在编码过程中，运算过程几乎是独立的。作为一个概念模型，它要清晰得多。
第一语言的选择
Grigory：我想问一个非技术问题，在你看来，对于现在刚入门的软件开发人员或者是研究生和大学生而言，他们应该选择哪一种语言来作为他们的第一语言？
James：我回答这个问题可能会带有一点偏见，毕竟 Java 已经成功运行这么多年。我学的第一种编程语言是PDP-8汇编代码，随后是Fortran。大家可以去学习任何语言，有些人的接受能力更强，但这很大程度上取决于一个人最终的职业道路。如果你想成为一个软件开发人员，你要构建大型的、高性能的系统，运行在JVM上的语言最值得去学习，例如Scala和Kotlin，Clojure很有趣。如果你是物理专业的学生，Python是个不错的选择。
其实选哪一种语言都无关紧要，很多人都只是坚持他们学到的第一种语言，如果你能让人们反复学习各种语言，那肯定是最好的。我认为每个大学都应该为学生开设一门“编程语言”的课程。用五种不同的程序语言完成作业，这能加快学习进度，并且他们会发现这些语言的区别真的不大，同时也能让他们自己去思考，哪一种语言更好。很久以前我上过一门课，每次作业我都用最不合适的语言，例如，用Cobol语言进行数值计算，以及Fortran中的符号操作。令人惊讶的是，我的成绩依然是A。
如何看待“模式匹配”？
Grigory：下一个问题是关于模式匹配的。最近，它与Python、Ruby接轨，并且为不同的语言提出了建议。我们查阅了开发人员白皮书发现，目前并不能完全确定模式匹配在现代高级语言中的作用。您认为这种模式匹配思想，如何适用于Java、Python、Ruby或其他高级语言？我们真的需要模式匹配吗，或者它是特殊案例的特定用法?
James：对于新手来说，我认为编程语言中的“模式匹配”一词会造成误导。当我听到“模式匹配”这个短语时，我想到的是正则表达式。Simula有inspect语句，而inspect语句与许多模式匹配语句几乎完全相同。inspect语句是一个case语句，其中case标签是类型名，你可以执行：
Inspect PWhen Image do Show;When Vector do Draw;
因此可以把它看成是一个case语句，用case处理类型，大多数模式匹配语言的建议都是这样的。就我个人而言，我很喜欢，特别是应对C的隐形强制转换。在C之类的语言中，常常需要进行强制转换。如果你执行“inspect P When Image P do P ”，那么在case语句体中，P就是switch标签的类型，这让一切都变得简单多了。我很喜欢Simula中的inspect语句。我同意所谓“特殊案例”的说法，如果称之为“模式匹配”，但是它又不如正则表达式，就会有误导性，像一则虚假广告。但是抛开这些，我依然认为它的功能很强大。
可以将所有的语言联系到一起吗？
Grigory：还有最后一个问题。俄罗斯软件开发人员对JetBrains和Kotlin的开发倍感骄傲。Kotlin、Clojure和Scala等语言，在您创建的Java虚拟机、库、框架和现有代码生态系统上蓬勃发展。但是，这些语言都面临着挑战吗？能不能把这些语言都联系到一起呢？当有人试图用不同的语法对Java执行hotswap操作时，会遇到什么困难？
James：这要看你的目的是什么。Java虚拟机内置了许多安全性和可靠性的概念，主要与内存模型的完整性有关，诸如指针之类的东西，因此你不能伪造指针。对于C语言，如果你没有能力伪造，你将无法使用。如果你试图在JVM上实现C语言，并配置了严格的安全虚拟机，有些功能将无法实现。但是有些人所构建的虚拟机并没有严格的安全模型，并且没有内存分配模型。如果想要在C和Kotlin之间实现互操作，就必须放弃一定程度的安全性和可靠性。这就看你的取舍了。
在Java诞生之初，我的原则是：我不想调试内存损坏问题。在内存崩溃问题上我已经浪费了太多的时间，这个问题能消耗你几天的时间。我真的很讨厌追踪内存损坏bug。不过，每个人的喜好不同，可能有人认为花时间做这件事很有价值。也有人喜欢使用vi，在70年代和80年代它都是一个很好的编辑器。
Grigory：内存安全模型确实很重要，它提供了一些东西，但也造成了一些限制。非常感谢你，James！
原文链接：https://evrone.com/james-gosling-interview
附录1: JIT 编译原理
JIT(just in time):即时编译编译器，能够加速 Java 程序的执行速度。通常通过 javac 将java代码编译，转换成 java 字节码，JVM将字节码将其翻译成机器指令，逐条读入，逐条解释翻译。很显然，经过解释执行，其执行速度必然会比可执行的二进制字节码程序慢很多。为了提高执行速度，引入了JIT，它会在运行时把翻译过的机器码保存起来，以备下次使用。
JIT默认是启用的，JVM 读入 .class 文件, 解释后发给JIT编译器，然后它将字节码编译成本机机器代码，下图展示了该过程:
Hot Spot VM 编译
当 JVM 执行代码时，它并不立即开始编译代码。这主要有两个原因：
首先，如果这段代码只会被执行一次，那么编译就是在浪费精力。如果一段代码被多次执行，那么编译就非常值得了。因此，编译器具有的这种权衡能力会首先执行解释后的代码，然后再去分辨哪些方法会被频繁调用来保证其本身的编译。Java代码开始都是被编译器编译成字节码文件，然后字节码文件会被交由 JVM 解释执行，其实Java本身是一种半编译半解释执行的语言。
Hot Spot VM 采用了 JIT compile 技术，将运行频率很高的字节码直接编译为机器指令执行以提高性能（以 method 为翻译单位，还会保存起来，第二次执行就不用翻译了）直接执行。
第二个原因是最优化，当 JVM 执行某一方法或遍历循环的次数越多，就会更加了解代码结构，那么 JVM 在编译代码的时候就做出相应的优化。
把源代码翻译成机器指令，一般要经过以下几个重要步骤：
我们可以把将.java文件编译成.class的编译过程称之为前端编译。把将.class文件翻译成机器指令的编译过程称之为后端编译。
Java中的前端编译
前端编译主要指与源语言有关但与目标机无关的部分，包括词法分析、语法分析、语义分析与中间代码生成。
我们所熟知的javac的编译就是前端编译。除了这种以外，我们使用的很多IDE，如eclipse，idea等，都内置了前端编译器。主要功能就是把.java代码转换成.class代码。
词法分析
词法分析阶段是编译过程的第一个阶段。这个阶段的任务是从左到右一个字符一个字符地读入源程序，将字符序列转换为标记（token）序列的过程。这里的标记是一个字符串，是构成源代码的最小单位。在这个过程中，词法分析器还会对标记进行分类。词法分析器通常不会关心标记之间的关系（属于语法分析的范畴），举例来说：词法分析器能够将括号识别为标记，但并不保证括号是否匹配。
语法分析
语法分析的任务是在词法分析的基础上将单词序列组合成各类语法短语，如“程序”，“语句”，“表达式”等等.语法分析程序判断源程序在结构上是否正确.源程序的结构由上下文无关文法描述。
语义分析
语义分析是编译过程的一个逻辑阶段， 语义分析的任务是对结构上正确的源程序进行上下文有关性质的审查，进行类型审查。语义分析是审查源程序有无语义错误，为代码生成阶段收集类型信息。
语义分析的一个重要部分就是类型检查。比如很多语言要求数组下标必须为整数，如果使用浮点数作为下标，编译器就必须报错。再比如，很多语言允许某些类型转换，称为自动类型转换。
中间代码生成
在源程序的语法分析和语义分析完成之后，很多编译器生成一个明确的低级的或类机器语言的中间表示。该中间表示有两个重要的性质：
1.易于生成；
2.能够轻松地翻译为目标机器上的语言。
在Java中，javac执行的结果就是得到一个字节码，而这个字节码其实就是一种中间代码。
PS：著名的解语法糖操作，也是在javac中完成的。
Java中的后端编译
HotSpot虚拟机中内置了两个JIT编译器：Client Complier和Server Complier，分别用在客户端和服务端，目前主流的HotSpot虚拟机中默认是采用解释器与其中一个编译器直接配合的方式工作。
热点检测
要想触发JIT，首先需要识别出热点代码。目前主要的热点代码识别方式是热点探测（Hot Spot Detection），有以下两种：
1、基于采样的方式探测（Sample Based Hot Spot Detection) ：周期性检测各个线程的栈顶，发现某个方法经常出险在栈顶，就认为是热点方法。好处就是简单，缺点就是无法精确确认一个方法的热度。容易受线程阻塞或别的原因干扰热点探测。
2、基于计数器的热点探测（Counter Based Hot Spot Detection)。采用这种方法的虚拟机会为每个方法，甚至是代码块建立计数器，统计方法的执行次数，某个方法超过阀值就认为是热点方法，触发JIT编译。
在HotSpot虚拟机中使用的是第二种——基于计数器的热点探测方法，因此它为每个方法准备了两个计数器：方法调用计数器和回边计数器。
方法计数器。顾名思义，就是记录一个方法被调用次数的计数器。
回边计数器。是记录方法中的for或者while的运行次数的计数器。
附录2: Java 语言简史
Java是由Sun Microsystems公司于1995年5月推出的Java程序设计语言和Java平台的总称，最初推出的时候提出 “Write Once, Run Anywhere” 的理想愿景。
Java是一门面向对象编程语言，不仅吸收了C/C++语言的各种优点，还摒弃了C/C++里难以理解的多继承、指针等概念，因此Java语言具有功能强大和简单易用两个特征。Java语言作为静态面向对象编程语言的代表，极好地实现了面向对象理论，允许程序员以优雅的思维方式进行复杂的编程 。
Java具有简单性、面向对象、分布式、健壮性、安全性、平台独立与可移植性、多线程、动态性等特点 。Java可以编写桌面应用程序、Web应用程序、分布式系统和嵌入式系统应用程序等 。
用 Java 实现的 HotJava 浏览器（支持Java applet）显示了 Java 的魅力：跨平台、动态的Web、Internet计算。从此，Java被广泛接受并推动了Web的迅速发展，常用的浏览器现在均支持Java Applet。
技术应用
安卓应用
金融业应用服务器程序
网站开发
嵌入式
大数据
高频交易空间
科学应用
Java版本历史
JDK 1.0（1996）
Sun公司发布Java1.0，发布初期叫Oak，后改名为Java（JDK1.0基本上只支持Java语言基础特性）
JDK 1.1（1997）
引入内部类
引入JDBC：是Java语言中用来规范客户端程序如何来访问数据库的应用程序接口，提供了诸如查询和更新数据库中数据的方法。JDBC也是Sun Microsystems的商标。JDBC是面向关系型数据库的。
引入RMI：Java中一种特殊的类，可以将多个对象封装到一个对象（bean）中。特点是可序列化，提供无参构造器，提供getter方法和setter方法访问对象的属性。名称中的“Bean”是用于Java的可重用软件组件的惯用叫法。
引入JavaBeans：Java中一种特殊的类，可以将多个对象封装到一个对象（bean）中。特点是可序列化，提供无参构造器，提供getter方法和setter方法访问对象的属性。名称中的“Bean”是用于Java的可重用软件组件的惯用叫法。
支持反射能力
支持国际化和Unicode
J2SE 1.2（1998）
Java技术体系拆分为：J2SE、J2EE、J2ME
引入JIT：即时编译，又译及时编译、实时编译，动态编译的一种形式，是一种提高程序运行效率的方法。通常，程序有两种运行方式：静态编译与动态直译。静态编译的程序在执行前全部被翻译为机器码，而直译执行的则是一句一句边运行边翻译。
引入EJB技术
引入Swing图像化API
Java plug-in（Java Applet）：Web环境下的小程序
引入集合框架
J2SE 1.3（2000）
初次引入 HotSpot VM
Java命名和目录接口（Java Naming and Directory Interface，缩写JNDI）包含在主程序库中（先前为扩展组件的形式）
用于实现动态代理的类
J2SE 1.4（2002）
语言上的改变：assert 关键字（断言）
正则表达式
异常链，允许一个异常来封装原先处于较低级别的异常
支持 Internet Protocol version 6（IPv6）
非阻塞I/O（NIO）
新增 日志API
J2SE 5.0（2004）
泛型：为集合提供编译期间 （静态） 类型安全，且不须为大多数类型转换 （类型转换） （规范在 JSR 14）
元数据（MetaData）：也称作注解。让语言结构（像是类别和方法）能够用额外的数据标记，可以由元数据意识工具处理（规范在 JSR 175）
枚举
自动装箱拆箱：基本数据类型如int与Integer之间能够自动转换
静态导入（import static）
可变参数
JUC
For-Each 循环
Scanner 类别来解析来自各式各样的输入和缓冲
JavaSE 6（2006）
引入垃圾回收G1
优化锁与同步、垃圾收集、类加载等
@Override 接口
JavaSE 7（2011）
Sun被Oracle收购
钻石语法（泛型实例化类型自动推断）
try-with-resources语法糖
多个catch块用|连接
switch中可以使用字符串
支持动态语言
64位JDK的指针压缩
数值可加下划线
JavaSE 8（2014 LTS）
Lambda表达式（闭包，允许我们将函数当成参数传递给某个方法）
接口中的默认方法和静态方法
方法引用
无参构造器方法引用：类名::new 或者 Class::new
静态方法引用：Class::static_method （接受一个Class类型参数）
类成员方法引用：Class::method （没有参数）
实例成员方法引用：instance::method （接受一个instance对应类型的参数）
重复注解（同一个地方可以重复使用多次同一个注解，注解本身需要被@Repeatable修饰）
升级工具库实现
HashMap实现修改、ConCurrentHashMap实现修改
新增Stream API(java.util.stream)
新增Optional类以解决空指针问题
工具包，类依赖分析工具 jdeps
JVM方面：使用Metaspace（JEP122）代替方法区持久带（PermGen space）
JavaSE 9（2017）
JSR 376：在Jigsaw项目中将JDK模块化（参见Java平台模块系统条目）
JEP 222：jshell：Java Shell（一个 Java 交互式顶层构件）
JEP 295：AOT编译（通过 Graal VM 实现）[240]
JEP 268：XML Catalogs
JEP 266：更多的并发更新。包含响应式流的Java实现，及其部分替代品java.util.concurrent.Flow。
JEP 193：变量句柄：定义一个标准方法来调用java.util.concurrent.atomic和sun.misc.Unsafe操作的等价物。
JEP 282：jlink：Java链接器。该工具可以为模块生成一个包含了其所有依赖项的自定义运行时映像，同时允许生成一个包括运行它的JVM的可执行文件。
JavaDB被移出JDK
JEP 263：高DPI图像：自动缩放与尺寸自适应。
JavaSE 10 （2018.3）
JEP 286：局部变量类型推断 : var a = new ArrayList<>();
JEP 317：实验性的基于Java的JIT编译器。这是 Linux x64 下 Graal 动态编译器的集成。
JEP 310：应用程序类级别数据共享
JEP 322：基于时间的版本命名
JEP 307：适用于G1的多线程完全垃圾回收
JEP 304：垃圾回收器接口
JEP 314：更多的Unicode语言标签扩展
JEP 319：内置根证书
JEP 312：线程本地握手
JEP 316：在可选的内存设备上申请堆内存空间
JEP 313：删除本地代码头文件生成器javah
JEP 296：将所有JDK分支集成到同一个版本库中
JavaSE 11 （2018.9 LTS）
JEP 309：动态类文件常量
JEP 318：Epsilon：无操作垃圾收集器
JEP 323：lambda参数的局部变量语法
JEP 331：低开销堆分析
JEP 321：HTTP Client
JEP 332：支持 TLS 1.3
JEP 328：添加Java飞行记录器（JFR），其用于创建性能分析记录
JEP 333：添加ZGC（一个可扩展的低延迟垃圾收集器）
JavaFX、Java EE、CORBA 被移出 JDK
JEP 335：弃用 Nashorn JavaScript 引擎
JavaSE 12（2019.3）
JEP 189：Shenandoah：一个实验性的低延迟垃圾收集器
JEP 230：细粒度性能评审包
JEP 325：Switch 表达式（预览阶段）
JEP 334：JVM Constants API
JEP 340：仅保留一个 AArch64 平台的移植
JEP 341：默认类数据共享归档
JEP 344：针对G1，提供可中止的混合垃圾收集
JEP 346：针对G1，及时释放已申请但未使用的内存
.......
Java类库提升
附录3: James Gosling 历史采访
James Gosling on Java, May 1999
A Converstion with Java's Creator, James Gosling
by Bill Venners
June 15, 1999
First published in JavaWorld, June 1999
Summary
Java's Creator James Gosling talks with Bill Venners about the current state of the Java language.
On Wednesday, May 29, 1999 James Gosling, vice president and Sun fellow at Sun Microsystems and creator of the Java programming language, assessed the state of the Java language and platform in a phone interview with Bill Venners. In the course of the hour-long interview, Gosling discussed the current state of the Java programming language and the changes that are being considered for future versions of the language. Looking back to the Java language's early days, Gosling described the extent to which he had Jini technology in mind when he designed the Java language and the problems the Java platform solves in the enterprise. Gosling touched on those areas that have been a challenge for the Java language in the past and gave his impression of how they will be dealt with in the future.
The creator of the Java language also looked at how software and API development will change in the coming age of networked embedded devices. He explained why Jini technology's agree-on-interfaces approach to getting devices to work together on the network is superior to the traditional agree-on-protocols approach. In closing, Gosling shared his views about when it makes sense for developers to build a tool to solve the general case -- like he did when he invented the Java language -- and when it makes sense to concentrate on solving the specific problem at hand using available tools.
The Evolution of the Java Programming Language
Bill Venners: What has happened since the JavaOne show last spring that you think is significant in the evolution of the Java language?
James Gosling: The Java language itself has pretty much held constant. We've worked really hard to keep it very, very stable. We're being conservative about the Java language.
The kinds of things that have changed [since last year's JavaOne conference] have been implementations of the virtual machines underneath the language to give the language much higher performance, make it much more solid, and make it usable in many more situations. On top of the language we've done a lot of work with APIs. One of the key features of the language is this ability to define new facilities as classes. That's been where the explosion has really been: in all the APIs on top of the Java language itself. One main motivation for being conservative about the Java language and keeping it stable is so that all of this work on APIs that are on top of it doesn't get disturbed. Because that's where the real value is, in the stuff that's on top.
Bill Venners: What kind of changes can we expect to see in the language in the future?
James Gosling: There's a list of things that have been on the table for quite a long time. One of the things we get asked about a lot is type polymorphism, which shows up in C++ as its template maker. Five years ago, when I was trying to figure out the right thing to do as far as developing a new language, there were probably twice as many type polymorphism systems in the world as there were experts in type polymorphism. And nobody thought that anybody else's solution made any sense.
While there was a general feeling that there was something good about type polymorphism, exactly what it should look like was very unclear. There's been a really heated debate on this subject over the last few years. (There's a guy here named Gilad Bracha who's run herd on that debate, and a mailing list on the subject called the Java Genericity mailing list.) At this point we're down to about three proposals for type polymorphism, and it looks like we'll get to some kind of a resolution.
If you go to http://java.sun.com/people/jag/Presentations/COOTS99/index.html, you'll find a set of slides from a talk I gave in San Diego four weeks ago at COOTS 99, the Conference on Object-Oriented Technologies and Systems. In this talk, I go through unanswered questions concerning the Java language, including talking about what changes people have been asking for.
The number one thing people have been asking for is an assertion mechanism. Of course, that [request] is all over the map: There are people who just want a compile-time switch. There are people who think those are the spawn of the devil, and they want something that's more analyzable. Then there are people who want a full-blown Eiffel kind of thing. We're probably going to start up a study group on the Java platform community process. We've been using that process for everything, including language changes. There's already a study group starting up on type polymorphism, and a study group is also probably going to start up on assertions.
Performance and the Java Language
Bill Venners: Now that the Java HotSpot performance engine is released, to what extent is performance solved? Are there areas in which performance still can be improved? What future plans might you have for performance improvements?
James Gosling: Performance is one of those things that you're never done with. There is no system on the planet that is ever finished with performance. But our performance is getting pretty good. Lots of people do benchmarks of server applications, and compared to C and C++, we're basically right in the same ball park.
There is room for performance improvement in the new 2D graphics libraries in the Java 2 platform; these certainly need some tuning. One of the persistent performance problems we've had that has been pretty hard to grapple with involves the demand for features: people keep asking us to put this in and put that in. Look at "Project Swing," for example. "Project Swing" is this UI toolkit that is industrial-strength. It's got everything in there, and that makes it kind of big. And big always turns into a performance problem. So we're working on ways to try to make "Project Swing" faster, trim it down, and give it fewer interdependencies, so that it is fast and nimble.
It's this difficult paradox -- that the more there is, the more there is. In terms of the Java HotSpot performance engine, we've put out the first release of it, but there are more interesting optimization techniques that we would like to try which are not there yet. There are many more tricks in that particular bag, and there's a lot of room for it to grow.
Bill Venners: Can you be more specific?
James Gosling: One of the things that made HotSpot rather difficult is that it's a collection from some fairly large number of PhD theses -- a long esoteric list of dynamic compilation tricks. There were a bunch of things that have an awful lot of value that we decided not to do just to get Hotspot out there.
We do an awful lot of dynamic compilation tricks in the Java HotSpot performance technology now, but there's room to add more. Right now [performance-wise] we are as good as C or C++, often beating them, and it's pretty clear that we can get greater improvement out of it.
Another thing is that when you talk about optimizing something, it's often optimizing with respect to a particular situation. The current Java HotSpot technology release is targeted toward making server applications really fast. The kinds of tuning you do in server applications tend to be different than what you do in other places.
Inspiration for the Interface
Bill Venners: In Java you included multiple inheritance of interface, but left out multiple inheritance of implementation. Were you trying to say anything to designers by making the interface a separate construct? Were you trying to say anything by leaving out multiple inheritance of implementation? How did that come about?
James Gosling: It listened to people from the C++ and Objective-C camps, and I tried to sort out who had the most happy experiences. The Objective-C notion of a pure interface with no implementation seemed to have worked out really well for people. It avoids a lot of the sticky issues such as disambiguation that people get into in C++. It's still kind of messy. It's an area that I don't feel totally happy with.
Bill Venners: In what way?
James Gosling: Another way for doing these things is a technique called delegation. Some ideas in the delegation camp felt good, but I never came up with anything that really worked. I ended up with the interface construct, which felt simple enough to be comprehensible, sophisticated enough to be useful. It also avoided any of the tar pits that the other folks got into.
The Jini Vision
Bill Venners: I heard Java was originally envisioned for embedded devices. To what extent was Java designed with what would eventually come to be called Jini technology in mind? In other words, were you just thinking about embedded devices, or were you thinking about a Jini technology-like world?
James Gosling: Oddly enough, something very much like the Jini technology world was in there from day one. The very early version of the Java language, which was called Oak and ran on the Star Sevens, had a distributed message system in it that was very much like RMI. In fact, even though the original distributed message system got ripped apart when we started doing some of the cable television stuff, there was enough of it still lying around that when the RMI folks went to do RMI, they were able to fit in some of it.
Jini's Footprint
Bill Venners: What is the JDK footprint for Jini technology-enabled devices, and is that going to be a problem for people who are making devices where every tenth of a penny counts toward cost savings?
James Gosling: The Jini technology team has put a lot of effort into making it so that it can handle really teeny devices. To be technology-enabled, a Jini technology device doesn't actually have to have a full-blown Java virtual machine in it. All it has to be able to do is respond to messages over the network. And it has to be able to do a certain amount to identify itself and read class files out of ROM.
Homogeneous Execution Environments
Bill Venners: For mobile code to work, the Java platform needs to provide a homogenous execution environment, no matter where you go. That's been difficult to achieve for applets landing in just a few browsers. Is there something new that's going to help Jini service code see a more homogenous Java platform wherever it goes in all these different kinds of devices?
James Gosling: We really have had very limited problems with homogeneity for people who do tested VMs. The browsers turned into a real serious problem. There was Microsoft on the one hand that was just being evil. And then there was Netscape that ran into all kinds of engineering and financial difficulties. So the Java embedded in browsers was just turning into an unfortunate situation for us.
Bill Venners: But basically Sun developed a bunch of tests, and VM and API implementations that actually go through the tests are more homogeneous?
James Gosling: That story is quite different, certainly, for people who take pieces of Java technology-based code and squirt them around between servers and out to Oracle and the rest.
Bill Venners: Do you envision a solution to the browser problem?
James Gosling: We have a solution in place for Netscape 5.0, which hasn't been released yet. The general structure of the solution we're pursuing, that we like the best, is the Java Plug-in, which has been working out pretty well. What we need to do is make that more robust, deal with some delivery issues, and get it tied into the browsers better. But the basic direction for dealing with the browsers is taking the [Java] Plug-in product and making it industrial-strength.
Picking and Choosing APIs
Bill Venners: People who do embedded devices always seem to have this pressure to make things fit, which gives them the need to pick and choose which APIs they'll support. Is there some way of dealing with this pressure, such as somehow getting them to all have the same set of APIs?
James Gosling: Trying to get them to have the same APIs is why we came up with these API subsets. Some of that has worked, some of it hasn't. Much of what we've been trying to do lately has been to make it so these folks can do dynamic loading of pieces of the APIs that they don't support.
A certain amount of it has been trying to get people in the different industrial segments to get together and agree on what the common things are. But what should the standard APIs be that are available in a toaster? Or in some robot arm controller? They're very different.
Bill Venners: So what about the subsets, like Embedded Java and Personal Java? What's the status of those things then? It sounds like you've recognized that maybe you need to go into each little niche and help those people get together and figure out what APIs they need.
James Gosling: We figured that it was pretty much hopeless for us -- both hopeless and sort of arrogantly presumptuous -- to go into the different industrial segments and tell them what we think the API should be. For example, this is what we think the API should be for the GPS navigation system; this is what the API should be for telescope control; and so on. Those aren't things that we have any expertise in.
[What] we really have an interest in is making sure that the participants in those industries get together and figure it out. One of the things we try to do is facilitate matters where we can. So we might have a person or two who's involved in these efforts, but we certainly don't try to control them or drive them or run them.
How Software Development Will Change
Bill Venners: How will the emerging hardware environment of network-connected embedded devices change the way software and APIs are developed?
James Gosling: I think the biggest difference is that you can't just sit alone in a room and build stuff, because the things you're building interact with everything out there. You can't just sit alone and do whatever you want.
Bill Venners: And why is that?
James Gosling: Because you're trying to interact with other things, you have to know what the other things do. If there are multiple people doing similar kinds of things, they have to have some kind of an agreement on how these things should work. If you're designing an electrical power delivery mechanism, for example, you have to design a wall socket. And everybody has to use the same wall socket; otherwise those toasters won't be able to plug in to you.
It becomes an environment where people have to be much more socially involved. It really is a community thing.
The Idea Behind the Interface
Bill Venners: You once said that the core of object-oriented design is "figuring out what the interfaces are." Could you elaborate on that?
James Gosling: The interfaces are the things that connect the pieces. You've got a toaster and a power plug in the wall; it's the way you connect. The core of the object-oriented design thing is to try to figure out what the interfaces should be. The actual technology of object-oriented design in a programming language is how you express those interfaces.
From a developer'
以上是关于Java 之父 James Gosling 最新访谈：JIT 很好，但不适合所有语言的主要内容，如果未能解决你的问题，请参考以下文章
Java之父詹姆斯·高斯林 （James Gosling）学鸿蒙（HarmonyOS），HarmonyOS（鸿蒙）——Image组件详述