从 Kotlin 开发者角度看 Java 缺失的特性

作者 | Nicolas Fränkel

译者 | 明知山

策划 | 李冬梅

近二十年来，Java 一直是我的谋生工具，直到几年前我开始学习 Kotlin。

虽然 Kotlin 也被编译为 JVM 字节码，但有时候我还是不得不写一些  Java 代码。每次写 Java 代码时，我都不禁想，为什么 Java 代码看起来没有 Kotlin 那么好。我很想念那些可以提高代码可读性、表现力和可维护性的特性。

这篇文章并不是要抨击 Java，而是要列出一些我希望也能在 Java 中找到的特性。

不可变引用

Java 从一开始就有不可变引用：

• 类的属性；
• 方法的参数；
• 局部变量。

class Foo {
    final Object bar = new Object();      
    void baz(final Object qux) {                  final var corge = new Object();       }}

1. bar 不能重新赋值；
2. qux 不能重新赋值；
3. corge 不能重新赋值。

不可变引用在避免恶心的 Bug 方面起到很大作用。有趣的是，对 final 关键字的使用并不是很普遍，即使是在流行的项目中也是如此。例如，Spring 的 GenericBean 使用了不可变属性，但没有使用不可变方法参数或局部变量；slf4j 的 DefaultLoggingEventBuilder 没有使用这三个东西。

Java 允许你定义不可变引用，但不是强制的。默认情况下，引用是可变的。大多数 Java 代码没有使用不可变引用。

Kotlin 就没有给你这种选择：每个属性和局部变量都需要定义为 val 或 var。另外，不能重新给方法参数赋值。

Java 中的 var 关键字完全不同。首先，它只能用于局部变量。更重要的是，它没有提供与之对应的不可变的 val 关键字，你仍然需要添加 final 关键字，但几乎没有人使用它。

空安全 (Null Safety)

在 Java 中，我们无法知道变量是否为空。为此，Java 8 引入了 Optional 类型。从 Java 8 开始，如果返回 Optional 意味着实际的值可以为 null，如果返回其他类型则意味着值不能为 null。

但是，Optional 只针对返回值，不能用于方法的参数。为了解决这个问题，一些库提供了编译时注解：

显然，有些库主要针对特定的 IDE。此外，库之间很难兼容。因为库太多了，以至于有人在 StackOverflow 上问该使用哪一个。这些现象很能说明问题。

是否使用这些库是可选择的，而在 Kotlin 中，每种类型要么为空，要么为非空。

val nonNullable: String = computeNonNullableString()val nullable: String? = computeNullableString()

扩展函数

在 Java 中，扩展一哥类是通过继承来实现的：

继承类有两个主要问题。第一个问题是有些类不允许继承：它们使用了 final 修饰符。有几个被广泛使用的 JDK 类就是 final 类，例如 String。第二个问题是，如果我们无法控制的方法返回了一个类型，那么不管它是否包含我们想要的行为，都只能使用这个类型。

为了解决上述问题，Java 开发者发明了辅助类的概念，比如 XYZ 类对应的辅助类叫作 XYZUtils。辅助类提供了一系列静态方法，并带有私有构造函数，因此不能被实例化。这是不得已而为之，因为 Java 不允许方法存在于类之外。

通过这种方式，如果某个方法不存在于某个类中，辅助类就提供这样的一个方法，这个方法将这个类作为参数并执行所需的操作。

class StringUtils {                                          
    private StringUtils() {}                                 
    static String capitalize(String string) {                        return string.substring(0, 1).toUpperCase()            + string.substring(1);                               }}
String string = randomString();                              String capitalizedString = StringUtils.capitalize(string);

1. 辅助类；
2. 防止实例化这个类；
3. 静态方法；
4. 简单的首字母大写转换，不考虑极端情况；
5. String 类型不提供首字母大写转换函数；
6. 使用辅助类来实现这种行为。

之前，开发人员 需要在项目内部创建这样的类。现在，Java 生态系统提供了开源库，如 Apache Commons Lang 或 Guava。所以不要重新发明轮子了！

Kotlin 提供了扩展函数来解决同样的问题。

Kotlin 提供了不通过类继承或使用装饰器等设计模式来实现扩展类或接口的能力。这可以通过一种叫作扩展的特殊声明来实现。  例如，你可以为你无法修改的第三方库中的类或接口添加新函数。这些函数可以按照通常的方式进行调用，就好像它们就是原始类的方法一样。这种机制叫作扩展函数。  要声明扩展函数，需要用被扩展的类名作为前缀。

有了扩展函数，可以将上面的代码重写为：

fun String.capitalize2(): String {                                return substring(0, 1).uppercase() + substring(1);}
val string = randomString()val capitalizedString = string.capitalize2()

1. 自由的函数，不需要类；
2. Kotlin 的标准库中已经有 capitalize() 函数；
3. 调用扩展函数，就好像它属于 String 类一样。

需要注意的是，扩展函数是“静态”解析的。它们不会在现有的类上添加新的行为，只是假装会这样。生成的字节码与 Java 静态方法非常相似。它的语法要清晰得多，并且允许函数链接，这在 Java 中是不可能做到的。

具体化的泛型

Java 5 中引入了泛型。然而，语言设计者热衷于保持向后兼容性：Java 5 的字节码需要与 Java 5 之前的字节码完美地交互。这就是为什么泛型类型没有被写入生成的字节码中：这就是所谓的类型擦除。与之相反的是具体化的泛型，也就是说，泛型类型将被写入字节码中。

编译时泛型类型存在一些问题。例如，下面的方法签名将生成相同的字节码，因此，这些代码是无效的：

class Bag {    int compute(List<Foo> persons) {}    int compute(List<Bar> persons) {}}

另一个问题是如何从值的容器中获取类型化的值。下面是来自 Spring 的一个示例：

public interface BeanFactory {    <T> T getBean(Class<T> requiredType);}

开发者添加了一个 Class参数，这样就能够知道方法体中的类型。如果 Java 有具体化的泛型，就没有必要这么做了：

public interface BeanFactory {    <T> T getBean();}

想象一下 Kotlin 的具体化泛型。我们可以把上面的代码改为：

interface BeanFactory {    fun <T> getBean(): T}

然后这样调用函数：

val factory = getBeanFactory()val anyBean = factory.getBean<Any>()

1. 具体化的泛型。

Kotlin 仍然需要遵循 JVM 规范，并与 Java 编译器生成的字节码兼容。它可以通过内联来实现：编译器用函数体替换内联的方法调用。

下面是 Kotlin 代码示例：

inline fun <reified T : Any> BeanFactory.getBean(): T = getBean(T::class.java)

结    论

在这篇文章中，我描述了 Java 中缺失的 4 个 Kotlin 特性：不可变引用、空安全、扩展函数和具体化泛型。虽然 Kotlin 也提供了其他很棒的特性，但这 4 个对于 Java 来说已经是一大堆改进。

例如，通过扩展函数和具体化泛型，再加上一些语法糖，我们就可以轻松地设计 DSL，比如 Kotlin Routes 和 Beans DSL：

beans {  bean {    router {      GET("/hello") { ServerResponse.ok().body("Hello world!") }    }  }}

我知道，作为一种编程语言，Java 一直在改进，而 Kotlin 天生具备更强的灵活性。然而，竞争是好事，它们可以互相学习。

我只在必要的时候使用 Java，因为 Kotlin 已经成为我的 JVM 首选语言。

原文链接：

https://blog.frankel.ch/miss-in-java-kotlin-developer/

今日好文推荐

云计算的全球变局与中国故事

操作系统封闭、后台保守，为什么前端仍能一路狂奔？

软件架构如何“以不变应万变”

从维护性工作到软件开发革命，运维 15 年间的大逆转

点个在看少个 bug 👇