StarPocks 是一個將 Java class（們）自動轉換成 Mermaid.js class diagram 語法的工具。
0.0.1 版提供了下列功能：
備註：若後續有改動，此文件不會再更新，請改參考此文件
分為兩個部份：「class 定義」、「class 間的關係」。
由於 generic type 的定義哏（後敘），
先寫「class 定義」再寫「class 間的關係」比較保險。
直接上 SSCCE：
public class SpriteTestEP extends DrawComponent implements EntryPoint {
private RectangleSprite red = new RectangleSprite(200, 201, 100, 50);
private RectangleSprite none = new RectangleSprite(200, 201, 300, 50);
public SpriteTestEP() {
red.setFill(RGB.RED);
none.setFill(Color.NONE);
addSprite(red);
addSprite(none);
addSpriteOverHandler(new SpriteOverHandler() {
@Override
public void onSpriteOver(SpriteOverEvent event) {
log("Over : " + who(event.getSprite()));
}
});
addSpriteOutHandler(new SpriteOutHandler() {
@Override
public void onSpriteLeave(SpriteOutEvent event) {
log("Out : " + who(event.getSprite()));
}
});
}
private String who(Sprite sprite) {
return (sprite == red ? "red" : "none");
}
public static native void log(Object object) /*-{
console.log(
@java.lang.String::valueOf(Ljava/lang/Object;)(object)
);
}-*/;
@Override
public void onModuleLoad() {
//無關緊要，純粹 follow GXT 習慣 XD
Viewport vp = new Viewport();
vp.add(this);
RootPanel.get().add(vp);
}
}
操作步驟：
原文網址：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 的新功能與改變：
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 導致很難維護。instanceof 的 pattern matching 的 preview 二版。pattern matching 主要可以讓「在程式當中用特定條件取出 object 的 component」的表示法變得更簡潔。像 Haskell 跟 C# 都因為其簡約與安全的特性而包含 pattern matching。misc.Unsafe::defineAnonymousClass，這代表未來的版本會移除掉。同樣地，Java 語言並不會因為這個提案而有所改變。@JsAsync 跟 @JsEnum）做 compile，這會讓 GWT2 將可以用 J2CL 以及這些工具來 compile。NoSuchMethodException 的模擬。float[] 與 double[] 的 Arrays.binarySearch()。DiskCache 增加關閉的 hook 來清除暫存檔們。this 一定不是 null」String.regionMatches()。JsMethods 允許跟實做程式碼以相同名稱共存。Double.compare() 與 Float.compare() 正確地處理負 0。Arrays 現在有 implement Cloneable。AtomicReference 加到 gwt/emul。ScriptInjectorExecutorService 與 ScheduledExecutorService 的部份功能模擬。java.util.concurrent.Flow。javax.annotation{,.processing}.Generated。goog.global 沒有定義時，讓他變成 $wnd。when-linker-added element definition。Reader 以及 StringReader 模擬。DataflowOptimizer，用到時會發出警告。更多細節參見 commit log
最近想要在 UI component 出現 / 消失的時候自動做一些事情，於是打算從 GXT Component 下手。不過怎麼寫怎麼有問題，只好寫 n 個 SSCCE 來確認一下，實驗結果紀錄於此。
我關心這四個 method：
onLoad()onUnload()onShow()onHide()onLoad() 跟 onUnload() 是從 GWT 的 Widget 就定義的 method。理論上跟 onAttach()、onDetach() 等意，就是這個 component 加入到 DOM（或是從 DOM 中移除）時會觸發的 method。不過 API 都強烈建議用 onLoad() 跟 onUnload() 了，就乖乖照辦。
onShow()、onHide() 是 GXT Component 開始定義的 method，最常遇到的 caller 大概是 GXT Component 的 setVisible()（override UIObject）。
web server 的環境：
有一個功能是使用者按下按鈕後，web server 會用 JNA 載入印表機的 DLL，然後以程式控制列印內容。印表機不是實際連接到 web server，而是用網路印表機的方式連到 LAN 上頭某台使用者的 PC。
原文網址：http://www.integralist.co.uk/posts/http2.html
這是一篇很簡短的文章，展示如何利用新的 HTTP/2 通訊協定。如果你不熟悉它，那麼讓我花一點點時間來討論其中的一些亮點：
如果這些功能對你而言都不知所云，讓我作進一步的解釋……
故事是這樣的，專案的 project 海當中有一個是處理 Applet（不要問為什麼這個年代還在用 Applet，我後來改了一個 JWS 的版本，但是客戶還是想要保留 Applet [攤手]）。雖然這個 project 是 maven 結構，但是 sign jar 還有最後整合進去真正的 web project 都還是用人工手動作的（不要再問了，我都要落淚了）。
雖然千百個不願意碰這個 Applet project，但事情終究還是發生了，因為最底層的 library 升級了，所以不改不行，那就順便把他變得自動化一點吧… Orz
sign jar 當然是找 maven-jarsigner-plugin（以下簡稱 jarsigner），掛上去之後發現… 奇怪，怎麼始終 build 失敗？用他錯誤訊息噴出來的那個 Windows command 字串去執行看看（當然要把 keypass 跟 storepass 換回實際的字串）卻又沒問題。喔對了，似乎這個問題只會在 Windows 上頭重現… Orz
最後發現，問題不是出在 jarsigner 上，而是 project 當中本來就有掛的 maven-assembly-plugin（以下簡稱 assembly）造成的。因為如果拿掉 assembly 的設定、或是把 jarsigner 挪到 assembly 之前（這居然是某些人認為的解法… 完全沒意義阿… WTF），是可以正常運作的。
兩個 plugin 的官方 issue tracker 都有這件事情（jarsigner、assembly）。似乎是 assembly 2.2 版之後才會發生的事情，因為退回到 2.1 版就沒問題了，那就退回去吧… 祈禱不要踩到「為什麼要升級」的哏。
BUT…
希望 assembly 產生的檔名是乾淨的 foo.jar，所以加了 <finalName>、也加了 <appendAssemblyId>false</appendAssemblyId>，然後又開始 build 失敗了。問題點是卡在 <appendAssemblyId> 上頭。最妙的事情是… 這個問題在 2.2 之後解決了…
…………（嗶──）
好了，解法有兩個，一個是忘記 assembly 改成用 maven-shade-plugin，我用 2.0 版測試沒有問題，能滿足上述兩個需求。
另一個是… 把 assembly 提升到 2.6，也可以滿足上述兩個需求… （我沒有測 assembly 2.5 搭配 jarsigner 會不會出問題，但是 2.4 版是確定有問題的）
…………（嗶──）
我說那個 issue 可以麻煩順便關一關嗎？還是說根本是不知不覺間修好了，所以也沒發現......
這種排列組合的問題實在是很浪費生命阿… [淚目]
注意
這是一個沒學過圖學、線性代數也亂學的人寫出來的東西 (艸
input：
S 座標為 (sx, sy)E 座標為 (ex, ey)rx1、rx2、ry1、ry2。d
d = 0。箭頭向下是 d=90。變數：
w：abs(ex - sx)h：abs(ey - sy)x2：w * rx2 / (rx1 + rx2)y2：h * ry2 / (ry1 + ry2) / 2所以各點座標為：
A：(ex, (sy + ey) / 2)B1：(sx + x2, sy)B2：(sx + x2, sy + y2)C1：(sx, sy + y2)C2：(sx, ey - y2)B3：(sx + x2, ey - y2)B1：(sx + x2, ey)原文網址：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。
原文網址：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，因為我會假設他們處理一些我不知道的特殊狀況。不過它們搞出來的麻煩往往多過它們的價值。
原始報告請到 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 為篇名。
基本上都只翻譯數據跟（個人認定的）重點，非逐句翻譯。
4.47 分（滿分 5 分）。
這是 1101 份投票的平均分數。有 82% 的人投了 4 分以上。
作為 Sencha GXT 的團隊代表，我很高興宣佈 Sencha GXT 3.1 發布。在公開測試後只有一兩個月的時間，我們收到一卡車的回饋意見。我們已經解決幾個來自公開測試討論區的問題。感謝所有前期測試人員，你們的回饋意見始終是非常寶貴的。
GXT 3.1 導入了新的 Theme Builder（妝點 GXT 程式的新工具）、Neptune 這個佈景主題就是用 Theme Builder 做出來的；另外 GXT 3.1 也增加了對 GWT 2.6 的支援度。
（譯註：省略兩段純粹提供 3.1 各式連結的部份）
我大概是當完兵之後才開始用 HandlerManager 作 event bus，目的當然是降低耦合度。起手 reference 是 tkcn 的這篇《利用 HandlerManager 實作共用的 Event Bus》，然後一直以來就爽爽用，沒出啥問題、也沒想過會出問題。今天在 review 別人的 code 才知道有 SimpleEventBus，然後想知道這兩個到底有什麼差別、該用哪一個比較好？沒想到才剛打開 HandlerManager 的 source code，一開頭的 javadoc 就開始噴血：
application developers are strongly discouraged from using a HandlerManager instance as a global event dispatch mechanism.
WTF？不但不建議，而且是強烈不建議？GWT MVP 的文件都還是教用 HandlerManager 阿？
原文網址：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");
}
}
}
內容有點無腦，先把結論寫在前面：
外部 JS（官方文件稱為「handwritten JS」，其實不同 GWT Module 就滿足這個條件）要呼叫 Java 的 static method，必須先透過 JSNI 設定
$wnd.methodName = @fooPackage.FooClass::javaMethodName(*)，後續使用$wnd.methodName()來達到目的。關鍵在於 JSNI 中：
javaMethodName()後頭不需再加()。javaMethodName()的參數某些情況下可以省略 field descriptor，直接用*代替。
update：感謝 darkk6（ptt.cc）提醒，讓我發現我不但死腦筋，而且還少測了一種寫法… 所以文章就要重新翻修了 (艸
以往 Java 要操作檔案時，總得自己去面對 XXStream、XXReader、XXWriter，一不小心就迷失在 class hierarchy 迷宮中而搞不清楚到底該怎麼寫才好 [淚目]。NIO.2 的出現，提供了簡單好用的 method 來解決這些困擾。
這篇都還在 Java 7 的範圍。已經出的 Java 8 也對 NIO.2 做了一些改善，中文資料可先參考 Ingram Chen blog 的 File operation 章節。