自從JDK6之後,後續重大版本釋出前的固定戲碼,就是延期、延期、再延期,然而,自JDK9起,局勢有了重大轉變。不單是因為模組化實質上構築了新的Java平臺,後續的JDK版本在釋出週期上,也有了變化。

從JEP223到JEP322

自Java江山易主,版本的字串命名方式一直是耐人尋味的話題。單就下載JDK時,所看到的簡短版本字串形式來說,在7u40版本之前,u之後的數字,代表JDK是發布以來第幾個修正版,然而Oracle改變規則,為了彰顯出安全之類的重大修補(Critical Patch Updates)版本,採用奇數來命名,而臭蟲修正、API修改之類的維護版本,數字是偶數(另有版本號$MAJOR.$MINOR.$SECURITY格式,區分臭蟲修正或API修改)。

為此,之前既有的JDK6/7釋出版本,還被重新命名。就結論而言,重新命名之後,從7u9、6u37開始,就可以從奇偶數來辨別是否為重大修補版本;至於7u40之後的版本,重大修補是基於5的倍數,遇偶數加一,而維護版本會是20的倍數,如此(不直覺)的命名方式,被規範在JEP223之中。

然而,自JDK8之後,Oracle的Java架構長Mark Reinhold希望,未來Java發布可以基於時間,以半年為週期,持續發布新版本,讓一些有用的小特性,也能被開發者使用,因此,JEP 223的規範就不再適用了,而在JDK9釋出後,他們針對新版本曾經提出了基於$YEAR.$MONTH格式,然而,受到了社群極大的反對,為此,還提出了三個替代方案,收集各方意見(https://goo.gl/7CA8B3)。

那麼,Java下一個特性版本是?8.3?1803?還是10?調查結果顯示,社群大多數都支持10,Stephen Colebourne也發出懇求(https://goo.gl/i5J44T),並表示Java不像Ubuntu這類作業系統,基於$YEAR.$MONTH格式並不適合;到了最後定案,是採$FEATURE.$INTERIM.$UPDATE.$PATCH格式,規範在JEP322之中。

JEP322跟JEP223的命名格式上,有點類似,然而是基於時間,$FEATURE每六個月變更一次,必須包含新增的特性,$INTERIM目前總是為0,保留這個項目是作為未來使用之彈性,同一$FEATURE下,$UPDATE每三個月遞增一次,包含安全、臭蟲修正,而$PATCH只會在緊急的重大修補時遞增。

因此,對於Java SE 9來說,目前可以看到的版本,會是9.0.4這類的格式,至於2018年3月發布的特性版本為10,到了9月提供的新版本,就是11,JDK11預計會是長期支援版本,所以,在版本字串上,也會特別顯示LTS(long-term support)。

JDK10的var特性

無論如何,主版本是維持在大家熟悉的流水號格式了,而基於時間的釋出,可以看出Java想一掃過去總是延期的沉重感。然而,沉重並不只來自版本號,也來自於新興語言中靈活語法特性,帶來的壓力。基本上,Java對於語法新增,極為嚴苛看待,除非該語法被認為對開發產生極大助益,才有可能加入Java,不然,就會採用程式庫來加以實現。例如,在JDK8中實現了Optional,而不是讓多數開發者希望的貓王運算子(Elvis operator)?:成為語法之一。

然而,自JDK9之後,一些有趣的JEP引發了Java社群的熱議,像是JEP286中的var,用於區域變數型態推斷(Local-Variable Type Inference),例如, var name = "Justin",乍看與JavaScript沒有兩樣,然而,雖然沒有宣告型態,name的型態卻是String,這是從等號右邊的值推斷而來。

如果是泛型,我們可以撰寫為var names = new ArrayList<String>()這樣的形式,接著,names的型態上,就會自動推斷為ArrayList<String>。而對於更複雜的泛型應用,例如:如果我們撰寫成var nickNames = usernames.stream().map(this::getNickName).filter(Optional::isPresent),此時,編譯器所能自動推斷的nickNames形態,應會是Stream<Optional<String>>,若要進一步操作nickNames,結合開發工具提示,撰寫會簡潔許多。

更進一步地,var還讓匿名類別語法使用上更有彈性,可用來臨時擴充類別的特性或行為。

例如,底下語法可像JavaScript那樣臨時建立物件,並具有name、score特性與toXML方法,可透過o.name、o.score來存取,或用o.toXML()呼叫方法:

var o = new Object() {
String name = "Justin";
Double score = 88.5;
String toXML() {
return String.format(
"<name>%s</name><score>%.2f</score>", name, score);
}
};

這樣的語法可以運作的原理在於,匿名類別語法確實建立了一個匿名型態,只是在過去,開發者無法撰寫匿名型態的名稱來宣告變數,現在有了var自動推斷型態,變數可以自動獲取匿名型態,也就可以透過該變數來操作匿名型態上定義的成員。

如果使用過Scala、Kotlin之類的語言,對var應該不陌生,Java後來吸納這個特性,並由JDK10實現(社群進一步地期待可以有val來取代final),雖然只能用在區域變數(也就能用在for與try的宣告區),但就保守的Java來說,這已是跨出一大步。

未來的JDK

基於時間而發布的JDK,期盼每個版本都要有一到兩個重要功能,預計在9月發布的JDK11,目前已看到納入的JEP,有JEP323,可以在Lambda表示式的參數部份使用var,為的是有利於標註的修飾,可加註在Lambda表示式的參數之上。

比較要注意的是JEP320!JDK9已標註為廢棄的Java EE與Corba相關模組,將會在JDK11移除,在過去,Java有些API被廢棄,然而鮮少真正移除,就Java目前極力想展現輕盈來看,其他標示為廢棄的API,在未來的JDK版本,移除的可能性也會增加。

實際上,在JDK9模組化中,許多JDK內部API已經受到模組化的限制,而無法使用,或是使用時產生警訊。雖然可透過其他方式(像是非標準引數)繞過限制或警訊,然而,在未來版本JDK中,繞道而行的方式會移除,或者警訊將成為禁用。這些都意味著,Java想跳舞不單只是語法層面,還包含了平臺本身,為此,開發者本身也得及早因應。

雖然目前未出現在JDK11,但讓Java看來極力展現輕盈的JEP,還包含了JEP305的Pattern Matching,以及JEP325的Switch Expressions,對於用過Scala的開發者並不陌生。另外,還有個Java社群始終想要、卻死不加入的特性,也就是JEP326提出的Raw String Literals,開發者將來有機會擺脫惱人的字元跳脫(escape),以及用+來組成多行字串。

甚至還有個JEP草案,建議使用java HelloWorld.java來執行程式,而不用透過javac -d、java -cp……的形式,這讓人想到JDK9中附上的jshell,便於測試一些小程式。實際上,應該從JDK8開始,Java就試圖展現輕盈,Lambda語法及Stream相關API無非就是要素,就現在回顧,它們確實能極大程度來改變開發的風格與形式,並從中獲益,所以,JDK9的模組化,對於JDK本身的精簡,就更不在話下了。

Java已經歷經二十幾個年頭了,至今仍是重要的語言及平臺,若依然極力展現跳舞的努力及可能性,當然是好事,然而,更進一步該思考的是,為什麼一向被認為笨重的Java,也想努力舞動?

仔細瞭解加入Java、對開發程式有著重大影響的新語法,以及API、程式庫、模式、典範,知道它們從何而來、為了進入Java而做的改變,甚至作為重構既有程式的工具,試著探討與辨識,到底是哪些要素對Java產生如此強大的刺激,令它也想隨之起舞!

作者簡介


Advertisement

更多 iThome相關內容