微信号:frontshow

介绍:InfoQ大前端技术社群:囊括前端、移动、Node全栈一线技术,紧跟业界发展步伐。

我们与Kotlin的故事:从尝试到放弃

2018-05-28 17:48 无明 译
作者|Bartosz Walacik
译者|无明
编辑|覃云

Kotlin 现在很流行,它提供了编译时 null 安全,代码更加简洁。它比 Java 更好,你应该切换到 Kotlin,否则就只能坐以待毙。不过,在转向 Kotlin 之前,请先听听这个故事——在这个故事里,那些稀奇古怪的东西让我们忍无可忍,最后不得不使用 Java 重写整个项目。

我们尝试过 Kotlin,但现在开始使用 Java 10 重写代码。

我有一组自己最喜欢的 JVM 语言,/main 目录下的 Java 代码和 /test 目录下的 Groovy 代码是我最爱的组合。2017 年夏天,我的团队开始了一个新的微服务项目,和往常一样,我们讨论了要使用什么编程语言和技术。我们想尝试新的东西,所以决定试试 Kotlin。由于在 Kotlin 中找不到可替代 Spock 的测试框架,所以我们决定继续在 /test 目录中使用 Groovy(Spek 不如 Spock 好)。2018 年冬天,在使用 Kotlin 数月之后,我们总结了它的优势和劣势,并得出结论:Kotlin 导致我们生产力下降。于是,我们开始使用 Java 重写这个微服务。

原因如下:

  • 命名遮蔽(name shadowing)

  • 类型推断

  • 编译时 null 安全

  • 类字面量

  • 反向类型声明

  • Companion 对象

  • 集合字面量

  • Maybe 语法

  • 数据类

  • 公开类

  • 陡峭的学习曲线

命名遮蔽

Kotlin 的命名遮蔽对我来说是个最大的惊喜。比如下面这个函数:

fun inc(num : Int) {
    val num = 2
    if (num > 0) {
        val num = 3
    }
    println ("num: " + num)
}

当你调用 inc(1) 时会打印出什么?在 Kotlin 里,方法参数是按值传递,所以我们不能修改 num 参数。这样的设计是对的,因为方法参数本来就不应该被修改。不过,我们可以用相同的名字定义另一个变量,并将它初始化为任何想要的值。现在,在方法作用域内有两个名为 num 的变量。当然,现在一次只能访问一个 num 变量。所以从根本上说,num 的值被改变了。

我们还可以在 if 代码块中添加另一个 num(新的代码块作用域)。

在 Kotlin 中,调用 inc(1) 时会打印出 2,而在 Java 中,等效代码无法通过编译:

void inc(int num) {
    int num = 2; //error: variable 'num' is already defined in the scope
    if (num > 0) {
        int num = 3; //error: variable 'num' is already defined in the scope
    }
    System.out.println ("num: " + num);
}

命名遮蔽并非 Kotlin 独有,它在编程语言中是很常见的。在 Java 中,我们习惯用方法参数来遮蔽类字段:

public class Shadow {
    int val;

    public Shadow(int val) {
        this.val = val;
    }
}

Kotlin 中的命名遮蔽做得有点过了,这绝对是 Kotlin 团队的一个设计缺陷。IDEA 团队试图通过为每个被遮蔽的变量显示警告(“Name shadowed”)来解决此问题。两个团队都属于同一家公司,或许他们可以就遮蔽问题达成共识?我认为,IDEA 团队是对的,因为我想象不出遮蔽方法参数有什么用处。

类型推断

在 Kotlin 中,在使用 var 或 val 声明变量时,通常会让编译器根据右边的表达式猜出变量类型。我们称之为局部变量类型推断,这对程序员来说是一个很大的改进,我们因此可以在不影响静态类型检查的情况下简化代码。

例如,这行 Kotlin 代码:

var a = "10"

将由 Kotlin 编译器翻译成:

var a : String = "10"

这是 Kotlin 曾经比 Java 真正好的地方。我故意说“曾经”,那是因为 Java 10 现在也有了局部变量类型推断。

Java 10 中的类型推断:

var a = "10";

为了公平起见,我需要补充一点,Kotlin 在这方面仍然略胜一筹,因为在 Kotlin 中,可以在其他上下文中使用类型推断,例如,单行代码方法。

编译时 null 安全

null 安全类型是 Kotlin 的杀手级特性。在 Kotlin 中,类型默认是不可空的。如果你需要一个可空类型,需要添加?,例如:

val a: String? = null      // ok
val b: String = null       // compilation error

如果使用不带空值检查的可空变量,将无法通过编译,例如:

println (a.length)          // compilation error
println (a?.length)         // fine, prints null
println (a?.length ?: 0)    // fine, prints 0

一旦使用了这两种类型,不可空的 T 和可空的 T?,那么就可以避免出现 Java 中最常见的异常——NullPointerException。真的吗?事情并没有那么简单。

当需要将 Kotlin 代码和 Java 代码(库是用 Java 编写的,所以我猜经常会发生这种情况)混在一起时,事情就会变得很糟糕。于是,出现了第三种类型 T!。它被称为平台类型,代表 T 或 T?。或者更确切地说,T! 表示未定义可空性的 T。这种奇怪的类型无法在 Kotlin 中表示,只能从 Java 类型推断出来。T! 可能会误导你,因为它对空值放松了警惕,并禁用了 Kotlin 的 null 安全。

比如下面的 Java 方法:

public class Utils {
    static String format(String text) {
        return text.isEmpty() ? null : text;
    }
}

现在,你想在 Kotlin 中调用 format(String),那么应该使用哪种类型来使用此 Java 方法返回的结果?你有三个选择。

第一种方法,你可以使用 String,代码看起来很安全,但可能抛出 NPE。

fun doSth(text: String) {
    val f: String = Utils.format(text)// compiles but assignment can throw NPE at runtime
    println ("f.len : " + f.length)
}

你需要这样来解决这个问题:

fun doSth(text: String) {
    val f: String = Utils.format(text) ?: "" // safe with Elvis
    println ("f.len : " + f.length)
}

第二种方法,你可以使用 String?,这样就是 null 安全的:

fun doSth(text: String) {
    val f: String? = Utils.format(text)   // safe
    println ("f.len : " + f.length)       // compilation error, fine
    println ("f.len : " + f?.length)      // null-safe with ? operator
}

第三种方法,让 Kotlin 进行局部变量类型推断:

fun doSth(text: String) {
    val f = Utils.format(text)       // f type inferred as String!
    println ("f.len : " + f.length)  // compiles but can throw NPE at runtime
}

这段 Kotlin 代码看起来很安全,可以通过编译,但仍然会出现未检查的空值,就像在 Java 中那样。

还有一招,使用!! 操作符来强制推断 f 类型为 String:

fun doSth(text: String) {
    val f = Utils.format(text)!! // throws NPE when format() returns null
    println ("f.len : " + f.length)       
}

在我看来,Kotlin 类型系统中的!、? 和!! 太过复杂了。为什么 Kotlin 将 Java T 推断为 T! 而不是 T? 呢?Java 互操作性似乎损害了 Kotlin 的类型推断特性。看起来,我们似乎应该为所有通过 Java 方法赋值的 Kotlin 变量显式声明类型(如 T?)。

类字面量

在使用 Log4j 或 Gson 这些 Java 库时,经常会用到类字面量。

在 Java 中,我们在类名后面加上.class 后缀:

Gson gson = new GsonBuilder().registerTypeAdapter(LocalDate.class, new LocalDateAdapter()).create();

在 Groovy 中,类字面量被简化了,我们可以省略.class,不管它是 Groovy 类还是 Java 类:

def gson = new GsonBuilder().registerTypeAdapter(LocalDate, new LocalDateAdapter()).create()

而 Kotlin 则会区分 Kotlin 和 Java 类,并提供了语法规范:

val kotlinClass : KClass<LocalDate> = LocalDate::class
val javaClass : Class<LocalDate> = LocalDate::class.java

所以在 Kotlin 中,我们不得不这样写:

val gson = GsonBuilder().registerTypeAdapter(LocalDate::class.java, LocalDateAdapter()).create()
反向类型声明

C 语言家族使用标准方法来声明类型。简单地说,就是先声明一个类型,然后指定其他部分(变量、字段、方法等)。

Java 中的标准表示法:

int inc(int i) {
    return i + 1;
}

Kotlin 中的反向表示法:

fun inc(i: Int): Int {
    return i + 1
}

这种方式令人感到讨厌,原因如下。

首先,我们需要在名称和类型之间键入冒号。这个额外字符的意义何在?为什么名称与它的类型要分隔开?我不知道。只能说,这让 Kotlin 更难用了。

其次,一般来说,在查看一个方法的声明时,我们会先看方法名和返回类型,然后再查看参数。

而在 Kotlin 中,方法的返回类型可能远在行尾,所以需要滚动到最后面:

private fun getMetricValue(kafkaTemplate : KafkaTemplate<String, ByteArray>, metricName : String) : Double {
    ...
}

或者,如果参数按照行进行了格式化,则可能需要通过搜索才能找到返回类型。你需要花多少时间才能找到此方法的返回类型?

@Bean
fun kafkaTemplate(
        @Value("\${interactions.kafka.bootstrap-servers-dc1}") bootstrapServersDc1: String,
        @Value("\${interactions.kafka.bootstrap-servers-dc2}") bootstrapServersDc2: String,
        cloudMetadata: CloudMetadata,
        @Value("\${interactions.kafka.batch-size}") batchSize: Int,
        @Value("\${interactions.kafka.linger-ms}") lingerMs: Int,
        metricRegistry : MetricRegistry
): KafkaTemplate<String, ByteArray> {

    val bootstrapServer = if (cloudMetadata.datacenter == "dc1") {
        bootstrapServersDc1
    }
    ...
}

反向声明的第三个问题,IDE 对它的自动完成支持得不是很好。在标准的表示法中,可以很容易地根据类型名找到类型。在选定了类型后,IDE 会提供一系列候选变量名,这些变量名是从选定的类型派生出来的,所以你可以快速输入变量:

MongoExperimentsRepository repository

但即使是在 IntelliJ 中输入这个变量也是很费事的。如果你有多个 repository,则在自动完成列表中找不到正确的可选项,这意味需要手动输入完整的变量名。

repository : MongoExperimentsRepository

Companion 对象

一位 Java 程序员来到 Kotlin 面前。

“嗨,Kotlin。我是新来的,可以使用静态成员吗?“他问。

“不行,我是面向对象的,而静态成员不是面向对象的。“Kotlin 回答道。

“好吧,但我需要 MyClass 的 logger 对象,我该怎么办?”

“没问题,你可以使用 Companion 对象。”

“什么是 Companion 对象?”

“它是与类绑定的单例对象,可以把你的 logger 放在 Companion 对象中。“Kotlin 解释说“我懂了,是这样吗?”

class MyClass {
    companion object {
        val logger = LoggerFactory.getLogger(MyClass::class.java)
    }
}

“是的!”

“非常繁琐的语法,”程序员似乎感到困惑,“但没关系,现在我可以这样调用 logger——MyClass.logger,就像 Java 中的静态成员一样?”

“嗯……是的,但它不是一个静态成员!这里只有对象。你可以把它看作是已经实例化为单例对象的匿名内部类,但实际上这个类不是匿名的,它叫作 Companion,不过你可以忽略这个名字。是不是很简单?“

通过单例来声明对象的做法很管用,但是从语言中移除静态成员是不切实际的。在 Java 中,我们一直使用静态的 logger 对象。它只是一个 logger 而已,这个时候我们没有必要关心它是不是面向对象的,而且它并不会带来任何坏处。

有时候,我们必须使用 static,比如 public static void main() 仍然是启动 Java 应用程序的唯一方式。试着不使用谷歌搜索写出下面的 Companion 对象吧。

class AppRunner {
    companion object {
        @JvmStatic fun main(args: Array<String>) {
            SpringApplication.run(AppRunner::class.java, *args)
        }
    }
}
集合字面量

在 Java 中,初始化一个 List 需要很多代码:

import java.util.Arrays;
...
List<String> strings = Arrays.asList("Saab", "Volvo");

而初始化一个 Map 更加繁琐,所以很多人使用 Guava 来代替:

import com.google.common.collect.ImmutableMap;
...
Map<String, String> string = ImmutableMap.of("firstName", "John", "lastName", "Doe");

我们仍然在等待新的 Java 语法,可以简化集合和 Map 字面量的声明。而在其他很多语言中,已经有了便利的语法。

JavaScript:

const list = ['Saab', 'Volvo']
const map = {'firstName': 'John', 'lastName' : 'Doe'}

Python:

list = ['Saab', 'Volvo']
map = {'firstName': 'John', 'lastName': 'Doe'}

Groovy:def list = ['Saab', 'Volvo']def map = ['firstName': 'John', 'lastName': 'Doe']

简单来说,整洁的集合字面量语法是我们对现代编程语言的期待,特别是如果这门语言是从头开始创建的。Kotlin 提供了一堆内置函数:listOf()、mutableListOf()、mapOf()、hashMapOf() 等。

Kotlin:

val list = listOf("Saab", "Volvo")
val map = mapOf("firstName" to "John", "lastName" to "Doe")

键和值通过 to 操作符配对,这样很好,但为什么不使用众所周知的冒号呢?

Maybe 语法

函数式语言(如 Haskell)没有空值,相反,它们提供了 Maybe monad(如果你对 monad 不熟悉,请阅读 Tomasz Nurkiewicz 的这篇文章 http://www.nurkiewicz.com/2016/06/functor-and-monad-examples-in-plain-java.html)。

在很早以前,Scala 就将 Maybe 语法引入到了 JVM 世界,也就是 Option,然后 Java 8 也推出了 Optional。现在,Optional 是处理 API 返回类型空值的一种非常流行的方式。

Kotlin 中没有 Optional,所以似乎应该用 Kotlin 的可空类型来代替。

通常情况下,当你有一个 Optional 时,想要进行一系列 null 安全的转换,并在最后处理 null。

例如,在 Java 中:

public int parseAndInc(String number) {
    return Optional.ofNullable(number)
                   .map(Integer::parseInt)
                   .map(it -> it + 1)
                   .orElse(0);
}

也许会有人说,在 Kotlin 可以使用 let 函数代替 map:

fun parseAndInc(number: String?): Int {
    return number.let { Integer.parseInt(it) }
                 .let { it -> it + 1 } ?: 0
}

这样可以吗?可以的,但并没那么简单。上面的代码是错误的,parseInt() 会抛出 NPE。

只有当值存在时,monad 风格的 map() 才会被执行,null 会被忽略。可惜的是,Kotlin 的 let 函数与 map 不一样,它会从左侧调用所有的内容,包括 null。

所以,为了让代码变得 null 安全,必须在每个 let 前面添加?:

fun parseAndInc(number: String?): Int {
    return number?.let { Integer.parseInt(it) }
                 ?.let { it -> it + 1 } ?: 0
}

现在,比较 Java 和 Kotlin 版本的可读性,你更倾向哪个?

数据类

在实现 Value Object(也叫 DTO)时,Kotlin 使用数据类来减少样板代码,而在 Java 中,样板代码是不可避免的。

例如,在 Kotlin 中,你写了一个 Value Object:

data class User(val name: String, val age: Int)

Kotlin 负责生成 equals()、hashCode()、toString() 和 copy() 方法。

在实现简单的 DTO 时它非常有用,但请记住,数据类有严重的局限性——它们是 final 的。也就是说,我们无法扩展数据类或将其抽象化,所以你可能不会在核心领域模型中使用它们。

这个局限性不是 Kotlin 的错,因为我们没有办法在不违反替换原则的情况下正确生成基于值的 equals() 方法。这就是为什么 Kotlin 不允许继承数据类。

公开类

在 Kotlin 中,类默认是 final 的。如果想扩展一个类,必须添加 open 修饰符。

继承语法如下所示:

open class Base

class Derived : Base()

Kotlin 使用: 操作符代替 extends 关键字,还记得吗,这个操作符已经用于分隔变量名与类型。难道我们又回到了 C++ 语法?

颇具争议的是,在默认情况下,类是 final 的。但我们生活在一个满是框架的世界,而框架喜欢使用 AOP。 Spring 使用库(cglib、jassist)为 bean 生成动态代理,Hibernate 通过扩展实体类来实现延迟加载。

如果你使用 Spring,那么就有两种选择。你可以在所有的 bean 类前面加上 open(这很枯燥),或者使用这个编译器插件:

buildscript {
    dependencies {
        classpath group: 'org.jetbrains.kotlin', name: 'kotlin-allopen', version: "$versions.kotlin"
    }
}
陡峭的学习曲线

如果你认为你可以快速学习 Kotlin,因为你已经学过 Java,那么你错了。Kotlin 会让你陷入深渊。事实上,Kotlin 的语法更接近 Scala。你将不得不忘记 Java,切换到一个完全不同的语言。

相反,学习 Groovy 是一趟愉快的旅程。Java 代码与 Groovy 代码相得益彰,因此你可以从将.java 文件扩展名改为.groovy 开始。

最后的想法

学习新技术就像投资,我们投入时间,然后应该得到回报。我不是说 Kotlin 是一种糟糕的语言,但在我们的案例中,成本超过了收益。

  原文链接

https://allegro.tech/2018/05/From-Java-to-Kotlin-and-Back-Again.html

前端之巅

「前端之巅」是 InfoQ 旗下关注大前端技术的垂直社群。紧跟时代潮流,共享一线技术,欢迎关注。

  活动推荐

8月18日,我们将在一场面向技术人的区块链大会,大会关注目前区块链领域前沿技术与落地应用,将邀请国内外一线技术专家交流分享,和你一起探索区块链技术的更多可能!目前大会6折最后一周,火热招募中!扫描二维码进入官网查看大会议题。


 
前端之巅 更多文章 你是JavaScript大师吗?试试这些面试题就知道了 利用Nuxt.js创建服务端渲染的Vue.js应用程序 如果JavaScript成为第一个占领统治地位的编程语言,会怎样? 前端每周清单: Dojo 2.0,Excel支持JavaScript了,Kotlin使用率已达35% 为什么说Flutter让移动开发变得更好?
猜您喜欢 2018年7月份GitHub上热门Python开源项目排行 半个美国网络瘫痪,这才是真相! 『工欲善其事,必先利其器』-- 服务端压力测试工具的一些经验之谈 挣点钱咋就这么难——您到底想做个啥? 猿哥作品 WxaBlog1.1 版本发布