漫談JVM語言

好久沒聽到Java.next的話題了，這一次是Kotlin成為Android官方語言之一，連帶著Java又要死一次了。

所謂站在巨人的肩膀上看得較遠，其實是蓋在JVM上頭，搶市場較快，只是這次值得投資嗎？

簡化與增強

JVM上的語言也是不計其數，自己陸陸續續看過幾個，幾乎每個都是衝著Java語法的囉嗦與限制而來，有些是帶著新的典範而來，像是Scala，有的實際上與Java語法無關，像是Clojure，作為Lisp的一種方言，可以在JVM上執行，其實打著另一語言的招牌，可以取用Java生態圈現有資源的語言，也還有Jython、JRuby，連JavaScript也不缺席，而且這等肥水怎麼能外流，因此Java SE 7支援了dynamicInvok，而Java SE 8本身更直接附帶Nashorn。

衝著Java語法的囉嗦與限制而來的語言，我覺得做得最好的應是Groovy，再怎麼說，作為動態定型語言，Groovy連型態宣告都免了，大概是要省就省個徹底吧！Groovy瞄準Java開發者的目標很明確，許多語法關鍵字跟Java相同，有些程式碼甚至可直接貼到Groovy原始碼檔案之中直接執行，連改都不用改。

當然，Java太囉嗦了，我想，任何新語言只要隨便找個地方，都能做語法簡化，不能單只有這個特色，因此，通常在簡化之後，又會開始推銷著它們有著Java沒有的東西，像是API的增強，這部份若是有個強力的IDE，我會覺得省事許多。因為API的增強，其實等同於要學習一套程式庫，雖然一開始照著範例會覺得用得爽爽的，然而真要實用時，就得摸清這套程式庫的架構與設計，並不輕鬆。

此外，這些語言都痛恨NullPointerException，這應該是全體Java開發者的痛，因此像Groovy、Kotlin都有Elvis Operator，Scala是在API層面用了Option這類概念，Kotlin有趣的地方在於，變數宣告預設是不接受null的，若想要接受null，必須加上問號（?），更有趣的地方在於，如果開發者真的對NullPointerException有愛，還可以使用雙驚嘆號（!!），只要變數參考null，單是取用變數，就能直接噴個NullPointerException。

對於JVM上的語言，語法的簡化比較容易理解，只要開發者對Java的囉嗦有恨，多半不會有太大的抗拒性；然而，增強的部份就不是這麼一回事了。

同時，那些增強的語法、API ，或者是觀念、典範，往往需要更多的時間與知識背景去認識。我不確定那些增強的部份，對一個完全的初學者真的夠簡單，因為聲稱那些增強部份很好的人，多半是對Java或其他語言很有經驗的人，他們看到其他語言的優點出現在這些JVM語言上，當然拍手叫好了。

典範與賣點

如果單純就學習的角度來看，一門語言是否有獨樹一格的典範？能不能在學習的過程中，帶來不同的觀念與刺激？可不可能將相關的靈感過渡到其他的語言與開發中？都會是我決定深入投資一門語言時最重要的考量，畢竟能否採用某種語言，外在的因素太多，然而觀念在某些場合卻可以通用，這會使得投資一門語言的價值得以延續。

扣除Java這門語言不談（我最熟悉也從中學到最多東西），另一個讓我有觀念衝擊的是Scala，它的野心很大，試圖融合物件導向與函數式，堪稱史上最有野心的語言，我首次接觸到函數式典範就是在這門語言，事實上也證明，這門投資很值得，日後許多語言或多或少也都融入函數式風格，Scala也在資料處理的世界，找到具有賣點的舞臺，像是Spark，雖然可以用Java寫，但使用Scala還是比較對味。

Groovy一開始就是打著Java界的動態定型語言而來，而且挾帶著強大的meta-programming能力。如果開發者還有印象，應該會記起Groovy常與Ruby相比，也會記得Grails與Rails經常拿來對照。Groovy有著強大的DSL構造能力，後來也在Gradle找到了一個很棒的舞臺。同時，Spring大力支援Groovy作為配置文件的選項之一，動態定型是優點也是缺點（效能、工程考量等），不然的話，作為Java.next的候選人之一，Groovy本應該是最有機會坐上寶座的吧！

而Koltin就典範而言，並沒有給我什麼新穎的概念，許多東西都在Scala中看過了，要不就是來自於其他語言的元素，後者應該是新語言的通病，其他語言中好的東西都試著塞進來。我在看Koltin時，並不覺得它是Better Java，反而覺得它是Better Scala，它沒有強調函數式，也沒有Scala中那種符號或魔幻癖，是門務實的語言，如果Koltin跟Scala的誕生時間對調，Java開發者應該會很高興。

Kotlin成為Android官方語言之一，當然是個賣點，不過，它有個更大的特色，程式語言歷史上，C#是第一個開始就做到IDE強力支持的語言，而第二個就是Kotlin了，而且，這還難能可貴地發生在Java生態圈之內，Jetbrains一開始也是希望Kotlin能提高IntelliJ IDEA銷售率。因此，如果在介紹Kotlin的文件或書籍中，只把重點放在語法等，卻不提及任何有關IntelliJ IDEA的事，那大概都是不及格的。

共存與轉換

既然都是站在巨人的肩膀上搶巨人的市場，與現有的Java生態圈共存、互通資源有無，就是JVM語言必須面臨的課題，當然，它們都會聲稱與Java資源無縫接軌，實際上才不可能，想想看，Java本身每個新版本都為了相容性而傷腦筋了，開發者又怎麼能相信這些JVM語言無痛取用Java資源的口號？

首先，必須解決的就是型態對應的問題，身為一門常被稱為不純物件導向的語言，Java中還擁有基本型態是原因之一（據稱Java 10會拿掉？），而一些JVM語言會以更純綷的物件導向語言自居，就連數字等也是物件，因此，在型態的階層架構上，必然就會與Java有所不同了，最頂層型態不會是Object，而且可能會有個最底層的型態，像是Nothing之類。

想與現有的Java生態圈共存，最希望的是能寫JVM語言來取用Java資源，然而有時也必須是寫Java來取用JVM語言開發的東西。這代表著什麼呢？開發者必須同時掌握兩種型態系統、兩套語言的語法對應，還有兩套語言間的特例狀況。

例如，Java堅持的Checked Exception，這些JVM語言都有志一同地拿掉了，然而誰負責檢查Checked Exception呢？javac編譯器！如果用JVM語言開發的方法，想在Java中使用，又想要編譯器檢查Checked Exception的話，在JVM語言往往必須特別標注。這類需要特定關鍵字的情況雖然不多，但也不算少。

這些JVM語言必然可以找到不少文件，來談共存與轉換，也許有人覺得，最好是可以由程式自動化轉換，像是IntelliJ IDEA可以將Java轉換為Kotlin，這能解決一些瑣碎的轉換，不過，開發者還是要看得懂轉換後的程式碼，語言的對應負擔仍舊存在。

任何理性的語言都能取代Java？

每個人用Java的理由不同，而每個人想取代Java的理由也不同，也因此就像〈Why Kotlin Is Better〉（https://goo.gl/9udkew）談到的：「任何理性的語言都能取代Java」，不過也不用著急或擔心，畢竟它們都是打著Better Java的口號而來，想要的話，在幾天之內上手都不是難事，不這樣的話，這些語言在開發者開始麻煩之前，就會自己出局了。

取代Java的成本很高，因此，也不是幾天或幾個月之內就會發生的事情，這些JVM語言也都還要找到自己的舞臺，所以，並非各種場合馬上就變天。這是由於語言本身精良與否，也不是「取代」這件事最重要的考量，政治、商業性，以及一些因緣際會，這類難以預測的事往往佔了重要的比例，如果只是單純害怕Java被取代，而急著擁抱JVM語言，那只是表示，這個開發者才是最該被取代的人罷了。

喔！有個理由確實很難反駁，討厭Java現在的擁有者，只不過，這只能期得JVM語言有朝一日能真正走出JVM了，那真的就是Java.next了！