https://issues.apache.org/jira/browse/KAFKA-12895

背景故事

今天來講講比較沒那麼技術的東西，但是來引戰一下爲何Kafka要慢慢的跟Sacla漸行漸遠吧。很久很久以前，Kafka絕大多數的程式碼都是由Scala所開發，當然那是一個Java還不懂什麼是Functional的時代，所以相比之下，Scala獲得了許多的青睞和關注，身為一個優化的function工程師又怎麼能不被吸引呢？然而美麗的開始未必有著童話般的結局，隨著Kafka發展越來越多的功能，Scala一個非常致命的缺點就逐漸顯現出來，沒錯，那就是相容性。Scala作為一個後起之秀在還沒那麼多關注時，的確可以把相容性的優先權放低一點，然而隨著大規模採用以及使用者越來越多，版本之間的差異和破壞逐漸成為日後感情破裂的開始，就像一開始你可以忍受對方不洗碗衣服亂丟，但一天一個月一整年之後，這些小小的問題帶來的不滿會逐漸累積，尤其在Java 8的到來，原本Scala獨有的美色似乎也沒那麼特別，我們可以在Java 8中更自由的撰寫function，雖然還有一些限制但也足夠了，而這些還只是語言相關的問題。

再來則是程式碼的維護，在這個領域畢竟還是Java的天下，不管是開發者還是使用者，海撈一票懂Java的比比皆是，所以社群如果以長期運作為考量，那麼選擇生態系比較廣大的Java自然也是人之常情。所以早在很久以前Kafka就開始將客戶端的程式碼用Java來改寫，大家可能會好奇說為何是從客戶端開始？道理其實很簡單，就是前面提到的幾個原因，首先客戶端最需要有穩定的相容性，畢竟大家都喜歡無痛升級快樂使用，升個版本就要天翻地覆的搞一堆環境實在太累人，我們工程師何苦爲難工程師。第二個原因則是客戶端相對規模較小，萬事起頭難所以選一個相對好調整的可以避免整個社群的能量被耗盡。

當然客戶端的問題解決後，到今天自然就要討論伺服器端的改寫了。事實上這個改寫已經進行了好幾年，時到今日也還有一堆一堆程式碼依然以Scala的版本運行在伺服器端，不過儘管改寫之路漫長，我們依然在努力的要跟Scala說再見，而這個就是今天的主題，爲何我們要跟Scala 2.12說再見？其實也是跟相容性有關，這裏跟大家說一個Scala冷知識，不知道大家腦袋裡的大版小版是如何組成的？majro.minor.patch嘛？如果是的話，恭喜你有內建最常見的模式，但在Scala 2的世界裡面，大版其實是小數點第二個數字，換言之，Kafka其實很長一段時間都是同時支援兩個Scala 2大版，雖然在Kafka裡面真的感受到Scala 2.12和Scala 2.13不相容的地方其實不多，主要都集中在資料結構的部分，但在建構專案的時候依然要為了Scala 2.12和Scala 2.13分別發佈，這是因為我們不知道使用者會不會用到更多不相容的東西。

此外由於兩個Scala版本的差異，身為優秀且善良的社群，我們自然也要針對兩個不同Scala大版來作支援，這其實無形之間也增加了維護的成本，尤其社群也要注意避免寫出只能運行在Scala 2.13的程式碼，然後更不用說兩個大版在建構時的參數的差異，這可以在Kafka的建構腳本裡面清楚的看到，各種!= 2.12的邏輯其實都暗示Kafka為了能同時支援兩個大版花了多少心血 ...

解決辦法

講了那麼多其實只是希望Kafka的使用者可以理解一件事情，Scala曾經帶給我們無數的美好，但在這個離婚率高的時代，天下無不散的宴席，Kafka始終要跟Scala說再見，如此只是第一步也是一開始，希望這段旅程大家可以一起走過，就讓Scala留在美麗的回憶吧！

廣告

歡迎訂閱全臺最鬆散的開源社群源來適你，上面不定期會有各種開源的廢文。也歡迎參加全臺最鬆散的開源討論頻道，上面有一群網友一起在刷開源技術