毫無疑問，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 的可空型別。讓我們來調查一下這個問題。

通常情況下，當你有一個 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 很難， 但是我個人並不這麼認為。

最後的想法

從作者列舉的例子中，我感覺他只是瞭解語言的表面。

很難想象他對此有投入很多時間。

譯者：安翔，責編：郭芮

原文l連結：
https://allegro.tech/2018/05/From-Java-to-Kotlin-and-Back-Again.html
https://zsmb.co/on-from-java-to-kotlin-and-back-again/

歡迎關注我的微信公眾號「碼農突圍」，分享Python、Java、大資料、機器學習、人工智慧等技術，關注碼農技術提升•職場突圍•思維躍遷，20萬+碼農成長充電第一站，陪有夢想的你一起成長