好久沒聽到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了!

作者簡介


Advertisement

更多 iThome相關內容