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（細節略）

GWT 2.9.0 發布

亮點

• 可以用 jsinterop-base 1.0.0、elemental2 1.0.0、jsinterop-annotations 2.0.0（除了 @JsAsync 跟 @JsEnum）做 compile，這會讓 GWT2 將可以用 J2CL 以及這些工具來 compile。
• 增加 Java language level 9, 10, 11 的支援度。
• 正式停止在 Java 7 上執行 GWT compiler 與 server side tooling 的支援。在這個版本當中，GWT 還是可以在 Java 7 上 compile，但是不會保證能否運作。未來的版本會以 Java 8+ compile bytecode。這個版本用來測試與提供不同平台上搭配 Java 8, 11, 14 一起運作的方式。

棄用

• Elemental 已經正式棄用了，這個版本裡頭還有，但是未來的版本當中可能就不會出現。我們建議用 Elemental2 來取代，它可以同時用 GWT2 以及 J2CL compile。
• 移除 NoSuchMethodException 的模擬。

修正

• 修正 float[] 與 double[] 的 Arrays.binarySearch()。
• error / exception 增加支援多行訊息。
• DiskCache 增加關閉的 hook 來清除暫存檔們。
• 將 Gecko 版號快取起來，以減少在 FireFox 的 CPU 使用率
• 不再假設「this 一定不是 null」
• Updates globals for Firefox version 60.0.2, Chrome 66.0.3359.45。
• 修正 String.regionMatches()。
• 原生的 JsMethods 允許跟實做程式碼以相同名稱共存。
• 必要時，確保 lambda 的 box、unbox、insert 有消除 cast。
• Double.compare() 與 Float.compare() 正確地處理負 0。

雜項

• CLDR 更新到 v.34。
• Arrays 現在有 implement Cloneable。
• Link backing errors together with a cause attribute, start tracking suppressed errors in addition to the cause in underlying error object.
• AtomicReference 加到 gwt/emul。
• Propagate script nonces via ScriptInjector
• 增加 ExecutorService 與 ScheduledExecutorService 的部份功能模擬。
• 模擬 java.util.concurrent.Flow。
• 模擬 javax.annotation{,.processing}.Generated。
• 當 goog.global 沒有定義時，讓他變成 $wnd。
• 增加 when-linker-added element definition。
• 增加 Reader 以及 StringReader 模擬。
• 移除 GWT 版本檢查。
• synthetic method 不會顯示「unusable-by-js」警示。
• Update unmodifiableList to throw on Java8 methods.
• 預設關掉 DataflowOptimizer，用到時會發出警告。

更多細節參見 commit log

HTTP/2

原文網址：http://www.integralist.co.uk/posts/http2.html

---

引言

這是一篇很簡短的文章，展示如何利用新的 HTTP/2 通訊協定。如果你不熟悉它，那麼讓我花一點點時間來討論其中的一些亮點：

• 單一、持續的連線
• Multiplexing
• 壓縮 header
• 優先等級
• 加密
• Server Push

如果這些功能對你而言都不知所云，讓我作進一步的解釋……

理解 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。

啥時找 library？啥時自幹？

原文網址：http://games.greggman.com/game/when-to-find-a-library-vs-when-to-write-code/

譯註：我幾乎完全不認同這篇的說法，更不用說 HappyFunTimes 也是一個 library [大笑]。只是拿來恢復一下翻譯的感覺…

---

身為一個 C / C++ 碼農，除非是很大的 project，不然我很少找 library。舉例來說，如果我需要讀 BMP / TGA 檔，帳面上要寫的程式碼不到 100 行。看一下資料格式、寫一些程式、打完收工。要是我需要載入 JPG / PNG 這些格式異常複雜的檔案，我終究會去找一個 library。

我現在寫 JavaScript 就不太一樣，在 JavaScript 的世界中有數以萬計針對各種狀況的小型 library，讓我不知道該自幹程式還是找找看有沒有 library。這常常讓我覺得很浪費時間。

例如我要有一個非常簡單的功能：把字串裡頭的關鍵字換掉：

replaceParams("Hello %(name)s", {name: "World"});

// produces:
// Hello World

後來為了可以這樣搞，所以拓展到 20 行：

replaceParams(
    "Hello %(name)s from %(user.country)s",
    {
      name: "Joe",
      user: {
        country:"USA",
      },
    });

// produces:
// Hello Joe from USA

最近我希望可以用路徑插入其他檔案，像這樣：

replaceParams("->%(insertfile: foo/bar/moo.txt)s<-");

如果 moo.txt 裡頭是 this-and-that，結果會是：

-->this-and-that<--

只需要幾分鐘的時間就可以加這個功能，但是… JavaScript 中的 template 系統超級多，我建一個 template 很快。也許我應該去用那些 template 系統而不是重新再造輪。

那麼，第一個問題是：要用哪一個？我聽過 mustache、handlebars、jade、ejs…… 為什麼要選 A 而不選 B？我花了大概 20 分鐘搜尋、試圖比較… 來讓我知道哪一個比較優秀。我看到「ejs = 嵌入 JS」看起來很像 PHP；我看到 handlebars 是以 mustache 為基礎但是快了很多。我決定用 handlebars、花了大概 20 分鐘來改程式碼，它輸出相同的結果，一切看起來很棒。

然後我試著加上我那個 insertfile 指令，靠夭，炸了 AFAICT，除了關鍵字以外都沒辦法傳進 template 中。現在已經過了一小時了，誰能告訴我為什麼我要再作一次這件事情？

這就是為什麼寫這篇文章《啥時找 library？啥時自幹？》。當然，在這個例子中，如果我不去找 library 就可能只會花掉我 5～10 分鐘。我選用的 library 有一些功能，像是可以擴展功能… 自幹版當然也可以加功能。另外它可以選擇要不要轉換跳脫字元，自幹版當然也可以有這個功能。我其實沒有答案……

我知道的是… 找 library 讓我覺得分心、浪費時間。前頭我很誇張地描述許多我下載的熱門 library 證實是爛掉的，時間都花在找尋、設定跟測試。相對地，也有人告訴我應該使用更多 library。像最近在 HappyFunTimes 就有人說我應該用 body-parser 來自動分析 JSON 而不是自己處理。我的程式有 5… 也許 10 行，但是 body-parser 有 2000 行。好啦好啦，它能處理一堆 case，但是這些 case 在 HappyFunTimes 幾乎都不會遇到。我試了 body-parser 結果發現它也沒有處理我沒法處理的錯誤。如果我能解決這些錯誤，在網路上找答案是不會解決的，只會找到誰也遇到這個問題而且一樣沒辦法解決。

我想用 library，因為我會假設他們處理一些我不知道的特殊狀況。不過它們搞出來的麻煩往往多過它們的價值。

2014 年 GWT 調查報告中文摘要

原始報告請到 https://vaadin.com/documents/10187/4238532/GWT_report_2015.pdf 下載。 這個連結是在某個 G+ 上頭看到的， 目前 https:/vaadin.com/gwt 的連結還是指向 2013 的版本， 但是 https://vaadin.com/gwt/report-2015 的東西似乎 ready 了？

這是在 2014 年作的調查，所以雖然 vaadin 是標注 2015 年， 我還是以 2014 為篇名。

基本上都只翻譯數據跟（個人認定的）重點，非逐句翻譯。

---

1. 評價

4.47 分（滿分 5 分）。

這是 1101 份投票的平均分數。有 82% 的人投了 4 分以上。

Sencha GXT 3.1 發布

作為 Sencha GXT 的團隊代表，我很高興宣佈 Sencha GXT 3.1 發布。在公開測試後只有一兩個月的時間，我們收到一卡車的回饋意見。我們已經解決幾個來自公開測試討論區的問題。感謝所有前期測試人員，你們的回饋意見始終是非常寶貴的。

GXT 3.1 導入了新的 Theme Builder（妝點 GXT 程式的新工具）、Neptune 這個佈景主題就是用 Theme Builder 做出來的；另外 GXT 3.1 也增加了對 GWT 2.6 的支援度。

（譯註：省略兩段純粹提供 3.1 各式連結的部份）

GWT MVP part1

原文網址：http://www.gwtproject.org/articles/mvp-architecture.html

建立大型 application 都有其障礙，GWT application 也不例外。多個開發人員同時在一份程式碼上作業、維護既有功能，可能短時間內就會讓程式碼一團混亂。為了解決這個問題，我們導入 design pattern 來將 project 劃分出不同的責任區。

有很多 design pattern 可以選擇，例如 Presentation-Abstraction-Control、Model-View-Controller、Model-View-Presenter…… 等等。雖然每個 pattern 有其優點，不過我們發現 Model-View-Presenter（以下簡稱 MVP）架構在開發 GWT application 的效果最好。有兩個主要的原因：首先，就像其他 design pattern，MVP 會降低開發行為的耦合度，這讓多個開發人員可以同時工作。再者，MVP 會盡可能降低 GWTTestCase 的使用度。GWTTestCase 會需要 browser，但是大多數程式碼只要輕量、快速、不需要 browser 的 JRE 測試。

這個 pattern 的核心是把功能分散到各個元件，這在邏輯上是有意義的。但在 GWT 中還有一個明確的重點，是讓 View 的部份盡可能簡單，以減輕對 GWTTestCase 的依賴、降低整體的測試時間。

一旦你瞭解這個 design pattern 的原理，那麼建立以 MVP 為基礎的 application 就會直覺又簡單。我們將用一個簡單的通訊錄系統為例子，協助你聊解這些概念。這個系統可以讓使用者增加、編輯、檢視存放在 server 上的聯絡人清單。

死法無法預測

原文網址：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");
    }
  }
}

GWT RPC 的 deserialize 行為與 IE8

原文網址：http://blog.oio.de/2014/03/28/gwt-rpc-deserialization-vs-ie8/

---

幾乎每個 web 開發人員都知道，當 JS 執行時間過久 browser 就會跳出討厭的對話框問你要不要取消。在 IE 上頭會顯示「這個網頁的指令碼造成 Internet Explorer 執行速度緩慢」。

這篇文章將說明 IE8 的特殊行為、它如何影響 GWT RPC 的 deserialize 機制、以及如何解決這些問題。

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 了四個小時後，眼花撩亂的腦袋裡仍然是相同的問題：

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

App Engine 1.9.0 上線

原文網址：http://googlecloudplatform.blogspot.tw/2014/02/app-engine-190-now-available.html

---

今天我們宣佈 App Engine 1.9.0 發布，包含 Modules API general availability（GA）、新版 Java MapReduce library、以及加強 PHP runtime。

2013 年 GWT 調查報告中文摘要

原始報告請到 http://vaadin.com/gwt/report-2013 下載（要輸入 EMail 帳號）。 除了序言之外，其餘都只翻譯數據跟（個人認定的）重點，非逐句翻譯。

---

序言

在 2012 年第一次作 GWT 狀況調查 時，收到的回覆數量淹沒了我們。 我們把調查報告取名為《The Furture of GWT》（譯名：GWT 調查報告）， 因為我們想知道「GWT 衰老中」這個謠言到底有多少可信度。 在超過 1300 個回應裡，我們、以及全世界都看到了 GWT 活蹦亂跳的樣子。 許多大型企業用 GWT 來建構大型的 application， 對 GWT 投注的資源也在增加。

在《GWT 調查報告 2013 版》中， 我們想要知道 GWT 未來該如何發展？（第六節） 開發團隊在用什麼 Java 跟 GWT 的版本？以瞭解 哪些地方需要支援？（第四節） 你們需要哪些 extension、在找哪些 framework？（第五節） 為了取得背景以及人口統計學的資料， 我們也問了關於你的團隊（第一節）、 你在寫的 application（第二節）、 以及你如何開發 application（第三節）。 有了這些資訊整合成這份報告， 我們覺得這是最綜合性的調查，可以引領 GWT 很長一段路。

在 2013 年，有 12 月的研討會（gwtcreate.com）， 有令人興奮的 GWT 3.0 的計畫、 還有許多大公司投入 GWt 作為他們未來的技術； 我們知道 GWT 跨出了不只一大步。 2013 年 GWT 委員會也決定了未來的 release 步調： 每年一個大改版以及一個小改版。

這份調查是由 Vaadin、 Ray Cromwell（Google 代表、現任委員會主席）、 Daniel Kurka（mGWT 與 GWT-phonegap 的 Google 開發者）、 Artur Signell（Vaadin 代表）、 Bhaskar Janakiraman（Google）、 Colin Alworth（Sencha）、 Christian Goudreau（Arcbees）、 Konstantin Solomatov（Jetbrains）、 Mike Brock（RedHat）、 Stephen Haberman（Bizo）、 Joonas Lehtinen（Vaadin）以及 Thomas Broyer。 你可以在這份報告中看到他們的意見與反應。

這份調查報告在 GWT.create 2013 發表， 友超過 600 個熱心的 GWT 開發者出席這個年度最大的 GWT 活動。 我們同樣感謝超過 1400 位受訪者所花的時間與坦白， 期待看到你們的意見！

1. 關於開發團隊

團隊大小

GWT 開發團隊的平均人數是 12.5 人，而中位數則是 8 人。這跟去年的調查相同。 我們也問了過去 12 個月團隊大小的變化。

• 47%：一樣
• 41%：擴編
• 10%：縮編
• 3%：我只是小員工，不確定…

（兩張團隊大小的統計分佈圖）

團員組成

以八人團隊為例，任務分配為：

• 2.7 人：後端開發者
• 2.0 人：前端開發者
• 1.3 人：測試人員
• 0.9 人：PM（project / product）
• 0.6 人：設計師
• 0.6 人：死星上的人？

地理分佈

• 58%：歐洲（上升 8%）
• 25%：北美洲
• 8%：亞洲（譯註：可惡，我應該去參加調查的 [毆飛]）
• 4%：南美洲
• 2%：澳洲
• 2%：非洲

2. GWT 用在哪裡

畫面數量

• 48%：超過 20
• 22%：11～20
• 21%：5～10
• 10%：1～4

20 是一個魔術數字。調查大型 app 的畫面數量應該很有趣。

Christian：少於 5～7 個畫面的 app 實在太小了，為什麼會用 GWT 呢？ 這是個有趣的問題。

compile 時間

• 1～3 分鐘：27%（去年 31%）
• 3～10 分鐘：46%（去年 48%）
• 10～30 分鐘：20%
• 超過半小時：7%

對照去年的數據，可以代表 project 的規模越來越大。

Ray 與 Bhaskar：要改善 compile 時間有點難、需要一點時間來克服。 不過我們已經開始嘗試 incremental / modular compilation system。

寫給誰用

• 35%：內部使用
• 17%：公開且免費
• 43%：公開但收費
• 5%：其他

用來寫什麼

• 46%：商業內部 application
• 33%：商業外部 application
• 13%：content-rich 網站
• 2%：Portlet
• 1%：遊戲
• 5%：其他

Ray：看到有人用 GWT 寫遊戲實在很棒。 GWT 可以讓你在 Web 與 Android 之間共用程式碼， 藉由 PlayN 這種 library 也可以拓展到 iOS 上。

browser 支援度

（註：下列數據分別為 希望 2013 年有支援 / 希望 2014 年有支援）

• IE 6 跟 7：14% / 9%
• IE 8：54% / 44%
• IE 9：79% / 66%
• IE 10：80% / 76%
• IE 11：NaN / 70%
• Safari：18% / 62%
• Chrome：94% / 93%
• Firefox：94% / 92%
• iOS：NaN / 49%
• Android：NaN / 50%

Joonas：IE6/7 終於快死光了，所以 GWT 3.0 可以不用鳥它們了。 不過看起來 2014 年還是要很痛苦地去支援 IE8/9， 因為需求量看起來還是蠻大的。

Ray：對於改進 GWT 核心而言，IE6/7/8 是可悲的毒藥， 有很多 API 沒辦法增強就是因為老一輩的 browser 沒辦法處理。 網頁正轉型為 mobile 跟 HTML5， 要整合過時的 browser 會讓這個轉型過程變得很困難。

Thomas：看到 IE6/7/8 加起來還不少，讓我很沮喪。

裝置支援度

（註：下列數據分別為 2012 年 / 2013 年）

• Desktop：98% / 99%
• Tablet：36% / 45%
• Phone：26% / 30%
• 其他：2% / 2%

3. 如何用 GWT 建置 App？

怎麼作 UI？

• 48%：用 Java 刻
• 46%：UiBinder
• 6%：GWT designer

Christian：我不懂為什麼這年頭還會有人想要 Java 刻 UI？ 每個語言都有對應的 UI 描述方式。 ActionScript 有 MXML、 JavaScript 有 HTML、 .NET 有 XAML。

Daniel：看到這麼多人用 Java 刻 UI？ 明明 UiBinder 就是比較好的方式。我們需要大力推廣 UiBinder。

Mobile App 開發環境

• 27%：mGWT
• 16%：gwt-phonegap
• 16%：JS library
• 15%：PhoneGap
• 10%：Vaadin Touchkit
• 17%：其他

後端通訊方式

• 53%：GWT-RPC
• 11%：Request builder
• 7%：Request factory：
• 7%：自製
• 6%：Vaadin
• 4%：RESTY
• 3%：gwt-dispatch
• 3%：gwt-platform

Ray：GWT-RPC 在小型 app、快速開發方面實在超有力的， 但是在 compile 時間以及 interoperability 上會花很多時間。 JAXRS 是 GWT 3.0 考慮的方法之一，可能會提供更好的中間層。

Daniel：在決定 GWT 3.0 以後的 RPC 系統時， 我們應該要記得「很多人喜歡 GWT RPC 的簡單好用」這件事。

IDE

• 76%：Eclispe
• 18%：IDEA：
• 5%：Netbeans
• 1%：其他

Christian：我個人最愛 IDEA 的 GWT plugin，是目前最成熟的。

Ray：我是 IDEA 的愛好者，它把寫 JSNI/JavaScript 程式碼這檔事做的很好。

如何作測試？

• 49%：手動
• 18%：Selenium
• 13%：JUnit（GWTTest）
• 13%：沒有測試 UI 這種事啦…

DevMode 還是 Super DevMode？

• 74%：DevMode
• 14%：兩個都用
• 5%：Super DevMode
• 5%：孟獲孟獲孟獲…

Thomas：看到 Super DevMode 成長真好。 未來要讓所有 browser 支援 DevMode 不太可能。 Super DevMode 的比例成長應該有部份會歸應於 mobile 平台。

Joonas：我們真的應該讓 Super DevMode 變成預設值。 用它來執行程式會比較接近實際的運算效能。 我覺得 DevMode 的優勢在於設定比較方便。

4. 用什麼版本？

GWT 版本

• 79%：2.5
• 11%：2.4
• 3%：2.3
• 3%：trunk 版
• 2%：孟獲孟獲孟獲…
• 1%：2.1
• 1%：2.0

Thomas：看到有 3% 的人用 thunk 版真的超驚訝的。 我們計畫推出 nightly build，明年這個比率可能會增加。

JDK 版本

• 37%：Java 6
• 56%：Java 7
• 8%：Java 8

Ray：我可以發布一個解法，只讓 client 的碼用 Java8。 但是 Java6 無所不在，希望多一點人可以願意去試試看。 Java8 的 lambdas 超好的， 讓 async callback 還有 collection 操作變得很愉快。

Joonas：Vaadin 7 已經支援 Java 8 了， 我希望我們可以在 GWT 3 當中用到 Lambdas 的優點。

會在 client 端的程式碼用 Java 8 的功能嗎？

• 52%：不會讓 project 設定變複雜的前提下才會考慮
• 27%：希望 client 跟 server 端用不同版本的 Java
• 12%：沒興趣
• 6%：其他
• 2%：孟獲孟獲孟獲

Daniel：80% 的人會想要在 GWT 中用 Java8，這相當好。 我們必須找出一個好方法讓 server side 必須用 Java6 的人也能運作。

5. 外掛、framework…

GWT 用起來的產能如何？

• 不想再用：2%
• 不是很好：7%
• 中規中矩：32%
• 相當優秀：44%
• 無可匹敵：15%

下一個 project 會用 GWT 嗎？

• 84%：會
• 16%：不會

不用 GWT 會用什麼 framework？

• 5%：Play
• 5%：JSF
• 5%：Errai
• 6%：SmartGWT
• 8%：Dart
• 11%：SpringMVC
• 12%：Vaadin
• 14%：JavaScript
• 14%：Angular

Ray：GWT 3.0 會有一個新的 JS interop system， 銜接向 Polymar 或是 Angular 就不用寫 JSNI 的程式碼而變得更容易。 如此一來，想要用什麼 framework 就去用吧。

用哪方面的外掛？

回收的問卷中有 87% 的人使用了外掛，其中：

• 23%：UI 功能（例如 GWT-dnd、GWT-fx）
• 20%：application 架構（例如 GWT-presenter）
• 15%：資料存取（例如 GWT-rpc、GWT-dispatch）
• 12%：server 存取（例如 Google API、GWT-bootstrap）
• 9%：application 功能（例如 GWT-platform）
• 4%：data handling（例如 gilead）
• 5%：其他
• 13%：沒有用外掛

外掛去哪找？

• 55%：就 google 嘛
• 19%：自幹一個
• 13%：GitHub
• 11%：gwtproject.org
• 2%：其他

你會整合既有 JS 到 project 中嗎？

• 62%：會
• 32%：不會
• 3%：其他
• 2%：孟獲孟獲孟獲…

6. GWT 的未來

GWT 的 bug

• 73%：從來沒有回報過 bug
• 13%：有
• 14%：有，但是沒有修正

Thomas：GWT 真的夠好嗎？我不確定…… 到底是大家沒有被 bug 炸到，還是他們懶得回報 bug？

GWT 的光明面

每人兩票：

• 60%：產能（cross-browser、不用弄一堆 JS）
• 32%：執行速度（不是 compile 速度）
• 24%：可模組化（可以團隊方式寫 GWT，不會互相影響） （掌控大型、很多功能的程式）
• 19%：發現 bug 並解決的速度很快
• 18%：ecosystem 中的開發工具
• 17%：可靠度
• 13%：可用度
• 13%：產能（開始用 GWT 很容易）
• 9%：DevMode 的重新整理速度
• 7%：程式碼大小
• 6%：有很多 widget 可以用
• 5%：widget 品質很好
• 5%：設計 application 風格 / application 外觀
• 3%：有很多外掛
• 2%：外掛品質很好
• 2%：compile 時間
• 3%：其他

GWT 的黑暗面

每人兩票：

• 55%：compile 時間
• 29%：DevMode 的重新整理速度
• 19%：設計 application 風格 / application 外觀
• 13%：有很多 widget 可以用
• 13%：程式碼大小 （譯註：圖表的文字是 3%，但是長度是 13% 的大小。用後者。）
• 11%：發現 bug 並解決的速度很快
• 10%：產能（開始用 GWT 很容易）
• 9%：widget 品質很好
• 7%：ecosystem 中的開發工具
• 6%：執行速度（不是 compile 速度）
• 5%：可模組化（可以團隊方式寫 GWT，不會互相影響） （掌控大型、很多功能的程式）
• 3%：可用度
• 3%：有很多外掛
• 2%：外掛品質很好
• 2%：產能（cross-browser、不用弄一堆 JS）
• 1%：可靠度
• 6%：其他

Daniel：GWT 2.6 就已經有一些關於 compile 時間的改善。

Thomas：GWT 3.0 的重點會在改善 compile 時間以及 DevMode 的 refresh 時間上。

對委員會有什麼感覺？

• 17%：GWT 感覺比以前有活力
• 22%：對 GWT 的未來比以前有信心
• 17%：roadmap 更清楚了
• 28%：沒啥變化耶其實
• 10%：現在對 GWT 比較沒信心
• 6%：其他

GWT 的優點與缺點

原文網址：http://www.gmarwaha.com/blog/2011/05/09/gwt-pros-and-cons/

註：原文寫於 2011.05.09

---

我愛 JavaScript。jQuery 跟 MooTools 出來之後， 讓我對 JavaScript 的愛又增加了好多倍。 如果要我對所有我開發的 web application 做出選擇， 我會從上面兩個 framework 當中選一個。 但是在這一行，我不得不一次又一次地屈服於客戶的壓力、 用他們選擇的技術來作業，無論他們的選擇對或錯 （付錢就是老大啊...... Orz）。 有一個客戶讓我接觸到 GWT 的世界。

幾年前當 GWT 剛發佈的時候，我曾經試了一下。 我不怎麼喜歡，所以我甩了 GWT 就再也沒回頭看過它一眼。 但是在過去六個月用 GWT 作業之後，我對這個 framework 有稍微不同的印象。 我仍然不會說 GWT 是什麼拯救世界的神兵利器， 但至少它沒有我想像的那麼糟糕。 我把對這個 project 的觀察結果紀錄下來，好的壞的都有， 對之後要導入 GWT 的開發人員來說可能有點用處。

網路開始「閃爍（Blink）」

原文網址：http://blog.oio.de/2013/04/05/the-web-starts-to-blink-chrome-drops-webkit-as-its-rendering-engine-announces-blink/

副標題：Chrome 捨棄 WebKit，改用 Blink 作為 rendering engine。

感謝 LPH66 與 chingfen 校正 Chrome 語源

---

最近 WebKit 可能變成新一代 IE6 （在偉大的 browser 戰爭前，大多數網頁開發人員只為了相容 IE6 所作的最佳化與測試） 的說法逐漸成型。

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！

Dart 會是 Web 的未來嗎？

原文網址：http://highscalability.com/blog/2013/3/20/dart-is-it-the-future-of-the-web.html

John McCutchan 有很長一段職場生涯是在 Linux kernel 領域， 現在以程式碼最佳化大師的身份被挖去 Google 的 Dart 團隊。 這轉折還蠻令人好奇的，直到你看到這個影片： 〈透過 Dart 將 SIMD 帶進 web 領域〉。 John 說了同行都能懂的理由，他喜歡 Dart 有三個原因： 效能、效能、還是他媽的效能。