今年早期，在Azul Systems的技術博客上，公司技術副總Simon Ritter就Java 12的新特性發表了一篇文章。針對前期報道“JAVA 13 進入特性凍結階段”，InfoQ採訪了Ritter，內容涉及Java 12和13版本，以及Azul在Java 新版本推出後所採取的行動。
InfoQ：我們首先探討一下Azul的產品吧。你們提供兩個獨立的JDK產品，一個是自身的OpenJDK發行版Zulu，另一個是高性能專用JVM Zing。對於企業市場而言，這兩個產品有何差異？
Simon Ritter：Zing是我們的商業JVM產品，目標是優化對低延遲和高吞吐量有需求的Java應用性能。該市場針對的是在工作負載上具有很高要求的用戶。現有的垃圾回收機制存在非確定性的本質，無法處理此類工作負載
對於交易系統或網頁廣告注入等應用，它們無法容忍垃圾回收的暫停時間，而暫停時長取決於堆的規模。此類應用需要新的方法。Zing是提供了一種永不暫停的回收器。
Zulu是我們面向那些有意替代Oracle JDK的用戶而構建的OpenJDK。Oracle自JDK 11開始，更改了Java的發行許可證。這意味着許多依賴免費更新的用戶，現在必須面對付費使用Oracle或使用其他發行版的問題。Zulu企業版提供完整的SLA支持，以非常合理的成本提供更新。它適用於那些不受支持的免費版本無法適合自身需求的用戶。
InfoQ：確認一下，使用GPL許可的Zulu二進制文件是否支持自由重用？是否無需購買支持許可即可從Azul網站下載安裝運行文件？
Ritter：當然。我們提供了兩個版本的Zulu。其中，社區版可以從我們的網站免費下載，並自由使用。而企業版是受商業支持的版本，支持更新的SLA，並提供解決問題的支持渠道。
InfoQ： 你們也爲嵌入式系統提供了一款產品。對於你來說，它是如何融入企業整體發展的？
Ritter：我們還有第三條產品線，即Zulu Embedded。該產品不僅針對智能電錶、車載娛樂設備等真正的嵌入式系統，而且適用於那些希望將JDK與其應用代碼綁定以簡化安裝的用戶。
InfoQ：你能否介紹一下Zing（Azul專有JVM）的路線圖？Zing多年來一直提供獨具特色的C4垃圾回收器。該回收器是否正受到OpenJDK提供的新回收器的威脅（例如，ZGC和Shenandoah等）？企業如何應對不斷變化的JVM市場？
Ritter：從根本上說，我們一直在尋求可解決JVM相關性能問題的解決方案。儘管受控的運行時環境非常適於簡化開發和部署，但JIT編譯器在工作中依然存在垃圾回收暫停和應用預熱時間等不足。
爲解決垃圾回收問題，我們着手開發了C4（即“連續併發壓縮式回收器”，Continuously Concurrent Compacting Collector）。 儘管這些年C4做了一些改進，但通過加載值屏障（value barrier）和LVB的基本方法並未發生變化。
Shenandoah有別於C4，它採用了不同的方法，當前只使用了單一生成堆。而ZGC從方法上看更類似於Zing，並不能完全避免垃圾回收暫停。上述兩種回收器仍處於試驗階段，因此，我並不認爲很多客戶會在不久的將來將它們部署在生產環境中，尤其是那些尋求嚴格SLA的客戶。我們特別關注業界相關產品動態。
InfoQ：能介紹一下其它JVM子系統嗎？
Ritter：就在最近，我們將關注點轉向其它JVM部分。我們使用自身基於LLVM編譯器的Falcon JIT，替代了C2 JIT，這帶來了很大的性能改進，特別是在能以更好的方式處理向量等方面。爲降低預熱時間，我們開發了ReadyNow!。該技術對運行中應用做快照，進而使用快照加載並初始化類，並在到達主入口點之前編譯方法。
我們最新開發的特性是Compile Stashing。它可從應用運行過程中保存編譯代碼，並對代碼做高效緩存，降低了使用ReadyNow!所需的編譯量。在JVM規格說明中，對JVM啓動階段可做和不可做的事情給出了非常詳細的說明。這使得我們推出的全新理念可以通過TCK挑戰。
InfoQ：這些新技術是否會開源？未來是否會考慮開源？
Ritter：作爲商業產品，我們並沒有對代碼採用開源許可。未來是否會做出改變，尚需拭目以待！
InfoQ：Azul對非LTS版本Java有哪些經驗？用戶是否的確會在自己的生產系統中使用它們？?
Ritter：我在很多大會上談及此問題，並現場調查聽衆在生產環境中使用的JDK版本情況。很多人依然使用JDK 8，但越來越多的人正在遷移到JDK 11。從現場的舉手情況看，遷移到JDK 11的用戶比例大概在10-15%。這樣的非正式調研顯示，很少有用戶使用非LTS版本。
InfoQ：我們來談談Java 12，特別是新的Switch表達式特性。您認爲該特性的可用性如何？據您的觀察，是否有開發人員採用該特性？
Ritter：我認爲Switch表達式是一個很有用的功能，它澄清了Java語言中的一處模糊地帶。由於Java的主要語法都源自於C語言，因此Java必須處理類似於switch的語句，以不同的方式來實現，進一步對其進行簡化。
必須區分單個case表達式和不使用break就會出現問題，這即繁瑣又容易出錯。將switch作爲表達式（就像一條語句一樣）是很好的一種做法。因爲這樣只需要在代碼中做一次賦值，從而消除可能的錯誤來源。
不同於開發人員對lambda和stream特性讚譽有加，至今我尚未聽到Switch表達式的任何意見。這是因爲該特性僅在JDK 12中提供了，並且僅是作爲預覽特性，我懷疑在下一個LTS版本給出之前，該特性的使用都會很有限。
InfoQ：能整體介紹一下預覽特性（Preview Features）機制嗎？其實用性是否得到驗證？是否存在一些問題？
Ritter：我認爲這個機制很有效。Switch表達式是首個以預覽方式添加的功能，大家已體驗到該特性的優點。爲維持舊版本的外觀，JDK 12版本使用了帶值的break語句。
在編碼中，不能將數值作爲標籤使用。如果一併使用跳出循環到標籤處和switch語句表達式，同樣會造成混淆。考慮到代碼清晰化，在JDK 13中已決定改爲使用yield（即http://Java的現狀和未來：Azul System訪談">JEP 354）。如果某個特性並未作爲預覽功能，我們就難以搞清楚是否可以採用上述方式做出改進，因爲該語法已經包含在Java SE語言規範中。
InfoQ：您能對比一下語言的預覽特性與HTTP/2支持等孵化器API（Incubator API）這兩者嗎？ 在您看來，兩者之間存在哪些不同？
Ritter：孵化器模塊直接應用於API，而預覽語言功能主要涉及語言的語法。除此以外，二者毫無二致。二者都支持無需修改規範而添加新功能。可根據必要的反饋直接修改它們，甚至完全刪除，無需更改規範。二者對於Java平臺的深遠發展是頗有裨益的。
在我個人看來，儘早引入上述做法會使我們避免一些問題。
InfoQ：Java 13即將進入功能凍結階段。您對該版本有何看法？儘管從現在開始到9月份Java 13的GA發佈之間，不太可能再做出多少有意義地改進。
Ritter：JDK 13將同樣是一個並未包含許多功能改進的版本。目前看來，其中只添加了五個JEP計劃。開發人員不太可能第一時間就轉向使用此版本。JDK發佈的新節奏，出發點是穩定推出實現的新特性，使得用戶的變更速度跟上甚至超越原有的發佈時間表。
目前幾個大項目正在推進中，例如Valhalla、Loom和Panama。這些項目一旦發佈，版本中將包含許多新特性。重在保持Java的持續發展，避免停滯不前。
InfoQ：再聊聊“文本塊”（Text Blocks，先前稱爲“多行字符串”，multi-line string）特性。該特性是否可作爲沃德勒定律（Wadler’s Law）的一個實際體現？
Ritter：是的。有趣的是，似乎總是一些最小的特性反而得到更多的討論。Java過去曾出現過多次出現掉鏈子的問題。
大量實例表明，多行字符串有助於簡化某些語法。但是對於我這樣從JDK 1.0就開始使用Java編程的人而言，確實需要使用此特性的情況屈指可數。
InfoQ：最近OpenJDK郵件列表討論熱烈。在一些話題中，例如OpenJDK的Docker鏡像、Debian項目如何爲其版本獲取源代碼並構建二進制文件等，都有Azul工作人員的參與，尤其是Gil Tene。您能否概要闡述一下上述問題？您是否認爲這些問題已經得到了令人滿意的解決？
Ritter：被Gil描述爲“JDK亂燉”（mystery meat JDKs）的問題，是與濫用JDK二進制文件的版本字符串有關。一些可用的二進制文件中具有更新編號，用於尚未發佈的下次更新。
由此，問題在於用戶是否信任JDK 8u212事實上已經包含了指定的更新。JDK二進制文件具有多個來源，用戶顯然需要確認他們獲得了自身認爲需獲得的版本。在確定更新問題已得到解決之前，我們需要了解該機制在未來的更新中的工作方式。
InfoQ：鑑於OpenJDK 8已不再受Oracle管理，現在一項可能的舉措是反向移植（backport）那些Oracle曾不願意採用的功能或補丁。其中最突出的一項，就是Azul深度參與的Java Flight Recorder（JFR）向OpenJDK 8的反向移植。您能解釋一下反向移植的重要性、Azul的參與情況，以及相關補丁的最新情況嗎？
Ritter：Flight Recorder提供一組需構建到JVM中的功能，它支持收集JVM和應用執行情況相關的詳細度量。這些數據將被任務控制（Mission Control）應用使用。任務控制應用由Oracle開源提供，作爲Oracle JDK和OpenJDK間融合的組成部分。
Oracle JDK已將Flight Recorder集成到JDK 8中。因此，Flight Recorder仍然是一個商業功能，需要具有付費許可才能在生產環境中使用。現在Oracle JDK 8已經終止免費公開更新（至少對於商業用戶而言如此），人們正遷移到沒有Flight Recorder的OpenJDK 8版本。
正如你所說的，Azul一直致力於將Flight Recorder後向移植到OpenJDK 8中。目前，Flight Recorder已包含在我們的Zulu 8二進制文件中。我們正與其他OpenJDK貢獻者合作，使其成爲OpenJDK源代碼的組成部分。
InfoQ：Azul是否還參與了其它OpenJDK項目，或是對一些啓動項目有興趣？
Ritter：Azul深度參與了Java生態系統的方方面面。自2011年以來，我們就任JCP執行委員會成員；自Java SE 9發佈以來，我們就是Java SE專家組成員。我們的工程師Andrew Brygin是OpenJDK的項目牽頭人。此外，我們正持續對OpenJDK項目做出貢獻，例如JEP 285“旋轉-等待提示”（Spin-Wait Hints）。我們將繼續通過JUG訪問、資助AdoptOpenJDK活動等方式支持OpenJDK，乃至更大範圍的Java社區。
原文鏈接：