JDK 15 的新功能

原文網址：https://www.infoworld.com/article/3534133/jdk-15-the-new-features-in-java-15.html

Java Development Kit 15 是 Java SE 的下個版本，Oracle 的實做在 6/11 進入到初期的 ramp-down phase，該版本的功能集已經定型了。JDK 15 的亮點包含 text block、hidden class、foreign memory 存取 API 以及 sealed class、record 的 preview 版本。

Java upgrade 也進入到 ramp-down phase，兩個候選版本會在 8/20 之前釋出。general availability 會在 9/15。JDK 15 的前身是 3/17 發布的 JDK 14。Oracle 在 Java SE 保持著 6 個月發布一次新版的步調，每年會有兩個新的版本問世。

OpenJDK 15 的新功能與改變：

• 第二個 foreign memory 存取 API 的孵化版本，這可以讓 Java 程式安全且有效率地存取 Java heap 以外的 foreign memory。API 可以操作數種不同的 foreign memory，像是 native、persistent、managed heap。許多 Java 程式會存取 foreign memory，像是 Ignite、MapDB。這個 API 會協助避免產生與 garbage collection、跨 process 的 share memory、將檔案對應至記憶體的序列化… 相關的成本與不確定性。目前的 Java API 沒有提供令人滿意的 foreign memory 存取方法。但在新的提案當中，API 應該也不會損害到 JVM 的安全性。這個功能在 JDK 14 當中完成了早期孵化板，在 JDK 15 當中提供的是精鍊過的版本。
• sealed class 的 preview 版本。除了 interface，sealed class 限制其他 class 或 interface 如何繼承或實做 sealed class 的方式。這個功能的目標包含 class 或 interface 的設計者可以控制哪些程式碼是有實做的責任、提供一個比 access modifier 更具表達力的方法來限制 super class 的使用、以及 support future directions in pattern matching by underpinning the exhaustive analysis of patterns。
• 移除 Solaris/SPARC、Solaris/x64、Linux/SPARC 的支援。（細節略）
• record 是一種 class、它是 immutable 資料的透明載體。在 JDK 14 當中以前期 preview 版面世，JDK 15 應該會包含 preview 二版。這個計畫的目標包含設計一個 OO 建造法來表達一個簡單的數據集合、幫助程式設計師專住在建構 immutable data 而不是可繼承的行為、自動實做資料相關的 method（像是 equals 跟 assessor）、保持 Java 長期以來的原則（像是 nominal typing 以及移植能力）。record 可以視為是 nominal tuple。
• 基於 Edwards-Curve Digital Signature Algorithm (EdDSA) 的加密簽章演算法。EdDSA 是現代的 elliptic curve scheme 勝過目前 JDK 當中的簽章 scheme。EdDSA 只有在 SunEC provider 當中會實做。EdDSA 會被需要是因為相較於其他簽章 scheme 它加強了安全度及效能。一些加密的 library（例如 OpenSSL 跟 BoringSSL）已支援這個演算法。
• 重新實做古老的 DatagramSocket API，將底層 java.net.datagram.Socket 以及 java.net.MulticastSocket API 換成簡單且較現代的實做方式。這帶來幾點好處：1. 容易除錯與維護。2. 使用 Project Loom 正在開發的 virtual thread。新的計畫會依循 JEP 353（重新實做古老的 Socket API）。目前 java.net.datagram.Socket 以及 java.net.MulticastSocket 的實做可以回溯至 JDK 1.0，那時 IPv6 還在開發中。這造成目前 MulticastSocket 的實做試著調解 IPv4 跟 IPv6 導致很難維護。
• 預設關掉 biased locking，所有相關的 command-line 選項也都 deprecate。（細節略）
• 延續 JDK 14 的 preview 版本，推出 instanceof 的 pattern matching 的 preview 二版。pattern matching 主要可以讓「在程式當中用特定條件取出 object 的 component」的表示法變得更簡潔。像 Haskell 跟 C# 都因為其簡約與安全的特性而包含 pattern matching。
• hidden class 是無法讓其他 class 在 bytecode 當中直接使用的 class，這讓 framework 在 runtime 製造出 class 然後透過 reflection 的方式間接地使用這些 class。hidden class 可以被定義為 access control nest 的 member，並且可以獨立 unload。這個提案透過啟用標準 API 來定義無法被找到且有 limited lifecycle 的 hidden class，會增加所有 JVM 上語言的效能。無論 JDK 內外的 framework 將可以動態地製造 class 而不是定義 hidden class。許多在 JVM 上的語言依賴動態製造 class 來達到彈性與效率。這個提案的目標包含：讓 framework 定義找不到實做細節的 class，這樣其他 class 就無法連結到、也無法用 reflection 的方式發現到；support for extending an access control nest with non-discoverable classes；以及支援無法找到的 class 的侵入式 unload，這樣 framework 就有彈性可以想定義多少就定義多少。另外一個目標是 deprecate 一個非標準 API misc.Unsafe::defineAnonymousClass，這代表未來的版本會移除掉。同樣地，Java 語言並不會因為這個提案而有所改變。
• Z Garbage Collector（ZGC）將從實現性質的功能轉變成產品。2018 年 9 月整合進 JDK 11 的 ZGC 是一個可拓展、低延遲的 GC。ZGC 以實驗性功能的身份導入，是因為 Java 開發人員認為 ZGC 的大小與複雜度應該小心地逐步帶入。從那之後補強了許多部份，ranging from concurrent class unloading, uncommitting of unused memory, and support for data-class sharing to improved NUMA awareness and multi-threaded heap pre-touching。heap 的最大值也從 4TB 增加到 16 TB。支援的平台包括 Linux、Windows 與 MacOS。
• text block 在 JDK 14 與 JDK 13 都出過 preview 版，要讓 Java 程式碼當中撰寫多行字串的工作便得簡單、同時避免大多數情況下的 escape sequence。一個 text block 是多行的字串，其中不包含 escape sequence、自動用可預測的方式格式化、並且提供開發人員控制格式的能力。A goal of the text blocks proposal is enhancing the readability of strings in Java programs that denote code written in non-Java languages. Another goal is to support migration from string literals by stipulating that any new construct can express the same set of strings as a string literal, interpret the same escape sequences, and be manipulated in the same fashion as a string literal. OpenJDK 開發人員希望增加 escape sequence 以管理明確的 white space 以及換行符號。
• Shenandoah low-pause-time garbage collector 從實驗性的功能轉變成產品。這在 JDK 12 時候導入，已經經過一年了。
• 移除 Nashorn。（細節略）
• Deprecation of the RMI Activation mechanism（細節略）

理解 Finalizer

原文網址：https://plumbr.eu/blog/debugging-to-understand-finalizer

---

這篇文章涵蓋了一個 Java 的內建功能：Finalizer。這個功能實際上廣為人知卻也鮮為人知，取決於你是否仔細看過 java.lang.Object。在 java.lang.Object 中有一個叫做 finalize() 的 method。它沒有實際的內容，但是它的威能與危險程度都取決於 JVM 內部如何處置這個 method。

當 JVM 偵測到 class 有 finalize() 這個 method，黑魔法就開始了。所以，我們來弄一個有不同 finalize() 的 class，這樣我們就能知道在這種狀況下 JVM 會如何處理這個 object。

死法無法預測

原文網址：https://plumbr.eu/blog/you-cannot-predict-the-way-you-die

---

在花了一天對付另一個 Heisenbug：每當我快抓到原因，它就會變了樣；我想我在這個 case 中學到的東西應該有分享的價值。

我寫了一個簡單的範例來展示這個狀況。在這個例子中，我建立一個 Map 然後用無窮迴圈往裡頭狂塞 key-value：

class Wrapper {
  public static void main(String args[]) throws Exception {
    Map map = System.getProperties();
    Random r = new Random();
    while (true) {
      map.put(r.nextInt(), "value");
    }
  }
}

NIO.2 的檔案操作

前言

以往 Java 要操作檔案時，總得自己去面對 XXStream、XXReader、XXWriter，一不小心就迷失在 class hierarchy 迷宮中而搞不清楚到底該怎麼寫才好 [淚目]。NIO.2 的出現，提供了簡單好用的 method 來解決這些困擾。

這篇都還在 Java 7 的範圍。已經出的 Java 8 也對 NIO.2 做了一些改善，中文資料可先參考 Ingram Chen blog 的 File operation 章節。

GC 對 throughput 與延遲時間的影響

原文網址：https://plumbr.eu/blog/gc-impact-on-throughput-and-latency

---

有一類問題是每一個 Java application 都會遇到的，那就是 GC。當 GC 正常運作時，它是一個美妙的發明；當它沒有運作、或是 GC 用出乎意料的方式運作，那你的朋友就會翻臉變成仇人。

這篇文章是關於 GC 造成的暫停時間。或著更精確地說：為什麼你要在意這些暫停時間？

如何估算記憶體需求？

原文網址：https://plumbr.eu/blog/how-to-estimate-memory-consumption

這個故事得從十年前開始說起，那時我第一次接觸到一個尖頭老闆的問題：「我們的產品要佈署的時候，需要買多好的 server？」在產品發表之後，我們花了九個月的時間打造了一個金光閃閃的新系統，顯然公司已經承諾要提供整個解決方案，包含硬體的部份。

囧… 我麻煩大了。我只有短短幾年的經驗，回答這問題跟丟骰子沒啥兩樣。雖然我看起來整個就是缺乏信心，不過我仍然得生出一個答案。在 google 了四個小時後，眼花撩亂的腦袋裡仍然是相同的問題：

「如何估算所需的運算能力？」

Java 8 取出 Collection element 的方式

原文網址：http://www.javacodegeeks.com/2013/03/extracting-the-elements-of-the-java-collection-the-java-8-way.html

譯文中的 Collection，代表 Collection API 或是屬於 Collection 的 class（List、Map...）。 如果是 collection，則代表某個 Collection 的 instance。

---

我們都廣泛使用 Collection， 像是 List、Map 以及延伸的 class。 每次我們用的時候，我們都得掃遍整個 collection 去找到某些 element、 更新它們、或是找出某個條件下不同的 element。 就像下面這個 Person 的 List：

拆穿 Java StringBuilder 的謠言

這篇文章的陳述方式及內容有許多問題，可參閱 ptt.cc Java 版後續的討論。

---

原文網址：http://skuro.tk/2013/03/11/java-stringbuilder-myth-now-with-content/

謠言......

用 + 號來連接兩個字串是萬惡的根源。 —— 不知名的 Java 開發人員

註：這裡討論用到的程式碼都可以在 Github 上找到。

在大學的時候，我學到在 Java 中用 + 號來連接字串是一種致命的效能罪惡。 最近在 Backbase R&D 有一個內部的 review， 這個 recurring mantra 變成了謠言， 因為當你使用 + 號來連接字串時，javac 會在底層使用 StringBuilder。 我要證明這件事情，並驗證在不同環境下的真實性。

Java 各種亂數產生器（PRNG）的弱點

原文網址：http://www.javacodegeeks.com/2013/03/weaknesses-in-java-pseudo-random-number-generators-prngs.html

這是 Kai Michaelis、Jörg Schwenk 還有我在 RA Conference 2013 的 Cryptographers' Track 發表論文的總結。 你可以取得我演講時的投影片、還有論文全文。 我們對常見 Java library 所產生的亂數序列進行分析， 這些 Java library 用了 PRNG（Pseudo Random Number Generator，通常是 SecureRandom）， 我們發現在特定條件下有明顯的弱點。 為了讓這篇文章盡可能簡短，各種 PRNG 所用的演算法、詳細的 bug 描述、 統計檢驗的結果都略過不提，但是論文裡頭都有。 我們的調查涵蓋 PRNG 本身、以及它們用來作 seed 的 entropy collector （例如沒有可用的實數產生器時）。 底線：需要品質良好的亂數時，不要使用 PRNG！

簡介 Java 8 的 default method

原文網址：http://www.javacodegeeks.com/2013/03/introduction-to-default-methods-defender-methods-in-java-8.html

我們都知道 Java 裡頭的 interface 僅包含 method 的宣告、並沒有實作的部份， 任何 implement interface 但又不是 abstract class 的 class 必須提供這些 method 實作。 看看下面這個例子：

functional interface：Java 8 重新製作的概念

原文網址：http://www.javacodegeeks.com/2013/03/introduction-to-functional-interfaces-a-concept-recreated-in-java-8.html

下面這些 interface，全世界各地的 Java 開發人員至少用過一個以上： java.lang.Runnable、java.awt.event.ActionListener、 java.util.Comparator、java.util.concurrent.Callable。 上述這些 interface 當中有一個共同的特點，就是它們只定義了一個 method。 JDK 當中有一堆這樣的 interface、Java 開發人員也製造了一堆。 這些 interface 也被稱為 Single Abstract Method interface（SAM interface）。 普遍常見的用法是產生一個 anonymous inner class 來使用這些 interface：

Java Collection API 的怪事

原文網址：http://www.javacodegeeks.com/2013/03/java-collections-api-quirks.html
感謝 tkcn 在 Java 技術上的協助。

在提到 Java Collection API 時，我們會認為已經了解全部的東西了， 像是 List、Set、Map、Iterable、Iterator。 我們已經準備好 補強 Java8 的 Collection API。

但在那之後，每隔一段時間我們就會偶然發現這些奇怪的怪事， 來自於 JDK 深處、以及向下相容的遙遠歷史。 讓我們來看一下這些不可修改（unmodifiable) 的 collection。

你懂 JIT compiler 了嗎？

原文網址：http://plumbr.eu/blog/do-you-get-just-in-time-compilation

還記得最後一次被寫 C 的人笑是什麼時候的事情嗎？ Java 真的有夠慢、慢到他們打死也不會考慮用這樣的語言？ 其實從很多方面來看，這種講法還是成立啦。 但是在大型企業的軟體骨幹中（這是 Java 的典型用途）， Java 的效能絕對可以跟其他技術相抗衡。 這可能都要感謝神奇的 JIT。 在解說 JIT compile 技巧前，讓我們先多講一些它的背景。

Java 的 method call 要付出多少代價？

原文網址：http://plumbr.eu/blog/how-expensive-is-a-method-call-in-java

我們都遇到過這種場景： 看著設計不良的 code，聽著寫出這 code 的人辯稱：「你不能為了設計犧牲效能啊！」 而你就是無法說服那個人放棄那有 500 行的 method， 理由是一連串的呼叫有可能降低效能。

Hibernate + HSQLDB 炸裂

測試環境：Hibernate 4.1.2、HSQLDB 2.2.8、Java 1.6

抓了兩個 H 的最新版，結果前後炸了四五個小時才能開始塞資料。茲紀錄如下。

大抵上是參考 《Hibernate 學習筆記》 （中文嘛...... [毆飛]），只不過 database 改成用 HSQLDB Server 版。

第一個遇到的問題是：只要一作 session.beginTransaction()，Hibernate 就會炸「No suitable driver found for jdbc:hsqldb:hsql://localhost/DBNAME」，最後找到的解法是在建立 Configuration 之前就先執行「Class.forName("org.hsqldb.jdbc.JDBCDriver")」。（參考資料：Hibernate forum）

順便補一下，似乎在 Hibernate 4 以後 Configuration.buildSessionFactory() 就被 deprecated 掉，不過（到目前為止）使用起來還是正常。至於標準寫法我沒研究，可參見 stackoverflow。

第二個遇到的問題是 session.save() 時 HSQLDB 會炸「user lacks privilege or object not found」，據說如果用 Hibernate 3.6 跟 HSQLDB 1.8 就不會有這種困擾...... Orz。這篇提到要將 Hibernate 的 hibernate.hbm2ddl.auto 設定為 create，實際上要設定成 update。參數之間差別如下：（參考資料：Hibernate reference）

• create：系統 init 時會作檢查 table 是否存在，有的話就會 drop 掉重建。
• validate：只有在 table 存在時，系統才能正常 init。
• update：理想狀況，init 時沒 table 會建，有 table 就續用。（不過如果系統運作中有外力 drop table，則會出錯）

做了這些手腳之後，目前 save() 之後東西都會乖乖進資料庫了。於是又寫一篇可能沒多久之後就沒意義的 debug / 教學文...... 軟體業阿...... [遠目]