再見，Kotlin ！你好，Java ！

毫無疑問，Kotlin 在去年很受歡迎，業界甚至有人認為其将取代 Java 的霸主地位。它提供了 Null 安全性，從這一點來說它确實比 Java 更好。那麼是不是這就意味着開發者應該毫不猶豫地擁抱 Kotlin，否則就落伍了？等等，或許事情并非如此。在開始使用 Kotlin 程式設計之前，本文想要分享個故事給你。在這個故事中，作者最早使用 Kotlin 來編寫一個項目，後來 Kotlin 的各種怪異模式以及一些其他障礙越來越讓人厭煩，最終，他們決定重寫這個項目。

以下為譯文：一直以來，我對基于 JVM 的語言都非常情有獨鐘。我通常會用 Java 來編寫主程式，再用 Groovy 編寫測試代碼，兩者配合使用得心應手。2017年夏天，團隊發起了一個新的微服務項目，和往常一樣，我們需要對程式設計語言和技術進行選型。部分團隊成員是 Kotlin 的擁護者，再加上我們都想嘗試一下新的東西，于是我們決定用 Kotlin 來開發這個項目。由于 Spock 測試架構不支援 Kotlin，是以我們決定堅持使用 Groovy 來測試。2018年春天，使用 Kotlin 開發幾個月之後，我們總結了 Kotlin 的優缺點，最終結論表明 Kotlin 降低了我們的生産力。于是我們使用 Java 來重寫這個微服務項目。那麼 Kotlin 主要存在哪些弊端？下面來一一解釋。名稱遮蔽這是 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，因為作用域的原因 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 團隊試圖通過向每個遮蔽變量顯示警告資訊來解決這個問題。兩個團隊在同一家公司工作，或許他們可以互相交流并就遮蔽問題達成共識。我從個人角度贊成 IDEA 的做法因為我想不到有哪些應用場景需要遮蔽方法參數。類型推斷在Kotlin中，當你聲明一個var或是val，你通常會讓編譯器從右邊的表達式類型中猜測變量類型。我們稱之為局部變量類型推斷，這對程式員來說是一個很大的改進。它允許我們在不影響靜态類型檢查的情況下簡化代碼。例如，這個Kotlin代碼：

var a = "10"           

Kotlin 編譯器會将其翻譯成： 

var a : String = "10"           

Java 同樣具備這個特性，Java 10中的類型推斷示例如下：  

var a = "10";           

實話實說，Kotlin 在這一點上确實更勝一籌。當然，類型推斷還可應用在多個場景。關于 Java 10中的局部變量類型推斷，點選以下連結了解更多：

• https://medium.com/@afinlay/java-10-sneak-peek-local-variable-type-inference-var-3022016e1a2b

Null 安全類型Null 安全類型是 Kotlin 的殺手級功能。這個想法很好，在 Kotlin 中，類型預設不可為空。如果你需要添加一個可為空的類型，可以像下列代碼這樣： 

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

假設你使用了可為空的變量但是并未進行空值檢查，這在 Kotlin 将無法通過編譯，比如：

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

那麼是不是如果你同時擁有不可為空和可為空的變量，就可以避免 Java 中最常見的 NullPointerException 異常嗎？事實并沒有想象的簡單。當 Kotlin 代碼必須調用 Java 代碼時，事情會變得很糟糕，比如庫是用 Java 編寫的，我相信這種情況很常見。于是第三種類型産生了，它被稱為平台類型。Kotlin 無法表示這種奇怪的類型，它隻能從 Java 類型推斷出來。它可能會誤導你，因為它對空值很寬松，并且會禁用 Kotlin 的 NULL 安全機制。看看下面這個 Java 方法：

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

假如你想調用 format(String)。應該使用哪種類型來獲得這個 Java 方法的結果呢？你有三個選擇。第一種方法：你可以使用 String，代碼看起來很安全，但是會抛出 NullPointerException 異常。

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

那你就需要用 Elvis 來解決這個問題：

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 的所有這些類似 scala 的類型系統過于複雜。Java 互操作性似乎損害了 Kotlin 類型推斷這個重量級功能。類名稱字面常量使用類似 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           

Kotlin 盡管有 IntelliJ 這樣強大的 IDE，輸入變量仍然是很難的。如果你有多個存儲庫，在清單中很難實作正确的自動補全，這意味着你不得不手動輸入完整的變量名稱。

repository : MongoExperimentsRepository           

伴生對象一位 Java 程式員來到 Kotlin 面前。

“嗨，Kotlin。我是新來的，我可以使用靜态成員嗎？"他問。 “不行。我是面向對象的，靜态成員不是面向對象的。” Kotlin 回答。 “好吧，但我需要 MyClass 的 logger，我該怎麼辦？” “這個沒問題，使用伴生對象即可。” “那是什麼東西？” “這是局限到你的類的單獨對象。把你的 logger 放在伴生對象中。”Kotlin解釋說。 “我懂了。這樣對嗎？”

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

“正确！” “很詳細的文法，”程式員看起來很疑惑，“但是沒關系，現在我可以像 MyClass.logger 這樣調用我的 logger，就像 Java 中的一個靜态成員？” “嗯......是的，但它不是靜态成員！這裡隻有對象。把它看作是已經執行個體化為單例的匿名内部類。事實上，這個類并不是匿名的，它的名字是 Companion，但你可以省略這個名字。看到了嗎？這很簡單。"

我很欣賞對象聲明的概念——單例很有用。但從語言中删除靜态成員是不切實際的。在 Java 中我們使用靜态 Logger 很經典，它隻是一個 Logger，是以我們不關心面向對象的純度。它能夠工作，從來沒有任何壞處。因為有時候你必須使用靜态。舊版本 public static void main() 仍然是啟動 Java 應用程式的唯一方式。

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

集合字面量在Java中，初始化清單非常繁瑣：

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

初始化地圖非常冗長，很多人使用 Guava：

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

在 Java 中，我們仍然在等待新的文法來表達集合和映射。文法在許多語言中非常自然和友善。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）。Maybe 很久以前就被 Scala 以 Option 引入到 JVM 世界，然後在 Java 8 中被采用為 Optional。如今，Optional 是在 API 邊界處理傳回類型中的空值的非常流行的方式。Kotlin 中沒有 Optional 的等價物，是以你大概應該使用 Kotlin 的可空類型。讓我們來調查一下這個問題。關注公衆号 逆鋒起筆，回複 pdf，下載下傳你需要的各種學習資料。通常情況下，當你有一個 Optional 的時候，你想要應用一系列無效的轉換。例如，在 Java 中： 

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

在 Kotlin 中，為了映射你可以使用 let 函數：

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

上面的代碼是錯誤的，parseInt() 會抛出 NPE 。map() 僅在有值時執行。否則，Null 就會跳過，這就是為什麼 map() 如此友善。不幸的是，Kotlin 的 let 不會那樣工作。它從左側的所有内容中調用，包括空值。為了保證這個代碼 Null 安全，你必須在每個代碼之前添加 let： 

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

現在，比較 Java 和 Kotlin 版本的可讀性。你更傾向哪個？資料類資料類是 Kotlin 在實作 Value Objects 時使用的方法，以減少 Java 中不可避免的樣闆問題。例如，在 Kotlin 中，你隻寫一個 Value Object ：

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

Kotlin 對 equals()、hashCode()、toString() 以及 copy() 有很好的實作。在實作簡單的DTO 時它非常有用。但請記住，資料類帶有嚴重的局限性。你無法擴充資料類或者将其抽象化，是以你可能不會在核心模型中使用它們。這個限制不是 Kotlin 的錯。在 equals() 沒有違反 Liskov 原則的情況下，沒有辦法産生正确的基于價值的資料。這也是為什麼 Kotlin 不允許資料類繼承的原因。開放類Kotlin 類預設為 final。如果你想擴充一個類，必須添加 open 修飾符。繼承文法如下所示： 

open class Base
class Derived : Base()           

Kotlin 将 extends 關鍵字更改為: 運算符，該運算符用于将變量名稱與其類型分開。那麼再回到 C ++文法？對我來說這很混亂。這裡有争議的是，預設情況下類是 final。也許 Java 程式員過度使用繼承，也許應該在考慮擴充類之前考慮三次。但我們生活在架構世界，Spring 使用 cglib、jassist 庫為你的 bean 生成動态代理。Hibernate 擴充你的實體以啟用延遲加載。如果你使用 Spring，你有兩種選擇。你可以在所有 bean 類的前面添加 open，或者使用這個編譯器插件： 

buildscript {
    dependencies {
        classpath group: 'org.jetbrains.kotlin', name: 'kotlin-allopen', version: "$versions.kotlin"
    }
}           

陡峭的學習曲線如果你認為自己有 Java 基礎就可以快速學習 Kotlin，那你就錯了。Kotlin 會讓你陷入深淵，事實上，Kotlin 的文法更接近 Scala。這是一項賭注，你将不得不忘記 Java 并切換到完全不同的語言。相反，學習 Groovy 是一個愉快的過程。Java 代碼是正确的 Groovy 代碼，是以你可以通過将檔案擴充名從 .java 更改為 .groovy。最後的想法學習新技術就像一項投資。我們投入時間，新技術讓我們得到回報。但我并不是說 Kotlin 是一種糟糕的語言，隻是在我們的案例中，成本遠超收益。

以上内容編譯自 From Java to Kotlin and Back Again，作者 Kotlin ketckup。他是一名具有15年以上專業經驗的軟體工程師，專注于JVM 。在 Allegro，他是一名開發團隊負責人，JaVers 項目負責人，Spock 倡導者。此外，他還是 allegro.tech/blog 的主編。

本文一出就引發了業内的廣泛争議，Kotlin 語言擁護者 Márton Braun 就表示了強烈的反對。Márton Braun 十分喜歡 Kotlin 程式設計，目前他在 StackOverflow 上 Kotlin 标簽的最高使用者清單中排名第三，并且是兩個開源 Kotlin 庫的建立者，最著名的是 MaterialDrawerKt。此外他還是 Autosoft 的 Android 開發人員，目前正在布達佩斯技術經濟大學攻讀計算機工程碩士學位。 以下就是他針對上文的反駁：當我第一次看到這篇文章時，我就想把它轉發出來看看大家會怎麼想，我肯定它會是一個有争議的話題。後來我讀了這篇文章，果然證明了它是一種主觀的、不真實的、甚至有些居高臨下的偏見。有些人已經在原貼下進行了合理的批評，對此我也想表達一下自己的看法。名稱遮蔽“IDEA 團隊”（或者 Kotlin 插件團隊）和“Kotlin 團隊”肯定是同樣的人，我從不認為内部沖突會是個好事。語言提供這個功能給你，你需要的話就使用，如果讨厭，調整檢查設定就是了。類型推斷Kotlin 的類型推斷無處不在，作者說的 Java 10 同樣可以簡直是在開玩笑。Kotlin 的方式超越了推斷局部變量類型或傳回表達式體的函數類型。這裡介紹的這兩個例子是那些剛剛看過關于 Kotlin 的第一次介紹性講話的人會提到的，而不是那些花了半年學習該語言的人。例如，你怎麼能不提 Kotlin 推斷泛型類型參數的方式？這不是 Kotlin 的一次性功能，它深深融入了整個語言。編譯時 Null 安全這個批評是對的，當你與 Java 代碼進行互操作時，Null 安全性确實被破壞了。該語言背後的團隊曾多次聲明，他們最初試圖使 Java 可為空的每種類型，但他們發現它實際上讓代碼變得更糟糕。Kotlin 不比 Java 更差，你隻需要注意使用給定庫的方式，就像在 Java 中使用它一樣，因為它并沒有不去考慮 Null 安全。如果 Java 庫關心 Null 安全性，則它們會有許多支援注釋可供添加。也許可以添加一個編譯器标志，使每種 Java 類型都可以為空，但這對 Kotlin 團隊來說不得不花費大量額外資源。類名稱字面常量:: class 為你提供了一個 KClass 執行個體，以便與 Kotlin 自己的反射 API 一起使用，而:: class.java為你提供了用于 Java 反射的正常 Java 類執行個體。反向類型聲明為了清楚起見，颠倒的順序是存在的，這樣你就可以以合理的方式省略顯式類型。冒号隻是文法，這在現代語言中是相當普遍的一種，比如 Scala、Swift 等。我不知道作者在使用什麼 IntelliJ，但我使用的變量名稱和類型都能夠自動補全。對于參數，IntelliJ 甚至會給你提供相同類型的名稱和類型的建議，這實際上比 Java 更好。伴生對象原文中說：

有時候你必須使用靜态。舊版本 public static void main() 仍然是啟動 Java 應用程式的唯一方式。

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

實際上，這不是啟動 Java 應用程式的唯一方式。你可以這樣做：

fun main(args：Array <String>){ SpringApplication.run(AppRunner :: class.java，* args)}            

或者這樣： 

fun main(args：Array <String>){ runApplication <AppRunner>(* args)}           

集合字面量你可以在注釋中使用數組文字。但是，除此之外，這些集合工廠的功能非常簡潔，而且它們是另一種“内置”到該語言的東西，而它們實際上隻是庫函數。你隻是抱怨使用:進行類型聲明。而且，為了獲得它不必是單獨的語言結構的好處，它隻是一個任何人都可以實作的功能。Maybe

如果你喜歡 Optional ，你可以使用它。Kotlin 在 JVM 上運作。

對于代碼确實這有些難看。但是你不應該在 Kotlin 代碼中使用 parseInt，而應該這樣做（我不知道你使用該語言的 6 個月中為何錯過這個）。你為什麼要明确地命名一個 Lambda 參數呢？資料類原文中說：

這個限制不是 Kotlin 的錯。在 equals() 沒有違反 Liskov 原則的情況下，沒有辦法産生正确的基于價值的資料。這就是為什麼 Kotlin 不允許資料類繼承的原因。

我不知道你為什麼提出這個問題。如果你需要更複雜的類，你仍然可以建立它們并手動維護它們的 equals、hashCode 等方法。資料類僅僅是一個簡單用例的便捷方式，對于很多人來說這很常見。公開類作者再次鄙視了，對此我實在無話可說。陡峭的學習曲線作者認為學習 Kotlin 很難， 但是我個人并不這麼認為。最後的想法從作者列舉的例子中，我感覺他隻是了解語言的表面。很難想象他對此有投入很多時間。