预定于3月17日发布的JDK 14马上就要来了！那么，JDK 14究竟有什么新功能，对于整天写代码、维护代码的开发者们来说，哪些功能最有用呢？

前沿资讯一网打尽”，作为一家专注Java教学的教育机构，下面就让动力节点带大家提前了解一下JDK 14的新功能！

来，快来一起围观吧~~~

…………………………………………………………………………………………………………………………………………………………

第14版包含的JEP（Java Enhancement Proposals，Java增强提案）比12版和13版加起来还要多。在这篇文章中，将主要讨论以下几点：

• 改进的switch表达式，第一次出现在Java 12和13中，在Java 14中获得了完全的支持

• instanceof支持模式匹配（语言特性）

• NullPointerException（JVM特性）

下面就跟我一起看下详细内容吧~~

一、Switch表达式

Java 14 中的switch表达式将会永久存在。如果你需要回忆一下什么是switch表达式，可以参考以前的这两篇文章（https://blogs.oracle.com/javamagazine/new-switch-expressions-in-java-12，https://blogs.oracle.com/javamagazine/inside-java-13s-switch-expressions-and-reimplemented-socket-api）。

二、文本块

有了文本块，就可以简化这一过程，只需使用三引号作为文本块的起始和结束标记，就能编写出更优雅的代码：

与普通字符串字面量相比，文本块的表达性更好。更多的内容可以参考这篇文章    （https://blogs.oracle.com/javamagazine/text-blocks-come-to-java）。

Java 14引入了两个新的转义序列。第一，可以使用新的 s 转义序列来表示一个空格。第二，可以使用反斜杠 来避免在行尾插入换行字符。这样可以很容易地在文本块中将一个很长的行分解成多行来增加可读性。

例如，现在编写多行字符串的方式如下：

在文本块中使用 转义序列，就可以写成这样：  

三、instanceof的模式匹配

Java 14引入了一个预览特性，有了它就不再需要编写先通过instanceof判断再强制转换的代码了。例如，下面的代码：

利用这个预览特性可以重构为：

由于条件检查要求obj为Group类型，为什么还要像第一段代码那样在条件代码块中指明obj为Group类型呢？这可能会引发错误。

这种更简洁的语法可以去掉Java程序里的大多数强制类型转换。（2011年的一篇针对相关语言特性的研究论文（http://www.cs.williams.edu/FTfJP2011/6-Winther.pdf）指出，24%的类型转换都来自于instanceof后的条件语句。）

JEP 305解释了这项改变，并给出了Joshuoa Bloch的著作《Effective Java》中的一个例子，演示了下面两种等价的写法：

这段代码中冗余的CaseInsensitiveString强制类型转换可以去掉，转换成下面的方式：

这个预览特性很值得尝试，因为它打开了通向更通用的模式匹配的大门。模式匹配的思想是为语言提供一个便捷的语法，根据特定的条件从对象中提取出组成部分。这正是instanceof操作符的用例，因为条件就是类型检查，提取操作需要调用适当的方法，或访问特定的字段。

换句话说，该预览功能仅仅是个开始，以后该功能肯定能够减少更多的代码冗余，从而降低bug发生的可能性。

四、Record

另一个预览功能就是record。与前面介绍的其他预览功能一样，这个预览功能也顺应了减少Java冗余代码的趋势，能帮助开发者写出更精准的代码。Record主要用于特定领域的类，它的位移功能就是存储数据，而没有任何自定义的行为。

我们开门见山，举一个最简单的领域类的例子：BankTransaction，它表示一次交易，包含三个字段：日期，金额，以及描述。定义类的时候需要考虑多个方面：

• 构造器

• getter方法

• toString()

• hashCode()和equals()

这些部分的代码通常由IDE自动生成，而且会占用很大篇幅。下面是生成的完整的BankTransaction类：

Java 14提供了一种方法可以解决这种冗余，可以更清晰地表达目的：这个类的唯一目的就是将数据整合在一起。Record会提供equals、hashCode和toString方法的实现。因此，BankTransaction类可以重构如下：

通过record，可以“自动”地得到equals，hashCode和toString的实现，还有构造器和getter方法。

要想尝试这个例子，需要用preview标志编译该文件：

record的字段隐含为final。因此，record的字段不能被重新赋值。但要注意的是，这并不代表整个record是不可变的，保存在字段中的对象可以是可变的。

如果你有兴趣阅读更多关于record的内容，可以阅读Ben Evans最近在《Java Magazine》上发表的文章（https://blogs.oracle.com/javamagazine/records-come-to-java）。

请继续关注该功能。从培养新一代的Java开发者的视角来看，Record也很有意思。例如，如果你要培养初级开发者，那么record应该什么时候讲呢？是在讲OOP之前还是之后？

五、NullPointerException

一些人认为，抛出NullPointerException异常应该当做新的“Hello World”程序来看待，因为NullPointerException是早晚会遇到的。玩笑归玩笑，这个异常的确会造成困扰，因为它经常出现在生产环境的日志中，会导致调试非常困难，因为它并不会显示原始的代码。例如，如下代码：

在Java 14之前，你可能会得到如下的错误：

不幸的是，如果在第5行是一个包含了多个方法调用的赋值语句（如getLocation()和getCity()），那么任何一个都可能会返回null。实际上，变量user也可能是null。因此，无法判断是谁导致了NullPointerException。

在Java 14中，新的JVM特性可以显示更详细的诊断信息：

Exception in thread "main" java.lang.NullPointerException: Cannot invoke "Location.getCity()" because the return value of "User.getLocation()" is null
    at NullPointerExample.main(NullPointerExample.java:5)

该消息包含两个明确的组成部分

• 后果：Location.getCity()无法被调用

• 原因：User.getLocation()的返回值为null

增强版本的诊断信息只有在使用下述标志运行Java时才有效：

下面是个例子：

在以后的版本中，该选项可能会成为默认。

这项改进不仅对于方法调用有效，其他可能会导致NullPointerException的地方也有效，包括字段访问、数组访问、赋值等。

六、总结