JUnit 5 想當共主，搞了個所謂的 JUnit Platform！
單就測試框架來說，JUnit 5 中應該是指 JUnit Jupiter 這塊。
JUnit Vintage 底層跑的，應該還是 JUnit 4，只不過多了層 JUnit Platform Engine，然後 JUnit Platform Launcher 透過 Engine 來跑 JUnit 4。
簡單來說，JUnit 4 還是 JUnit 4，只不過 JUnit 5 透過 JUnit Vintage 知道怎麼跑它。
如果有人想，可以實作一個 TestNG 的 [TestEngine1]，然後 JUnit Platform Launcher 也可以透過 Engine 來跑 TestNG 了，寫程式時照樣使用 TestNG 的 API。
只是說，如果我用 JUnit 4、TestNG 還是爽爽的，那就繼續用就好了啊？幹嘛中間還多個 JUnit Platform？如果不想使用 JUnit Jupiter 的話，確實就是如此，就架構看來，JUnit Platform 主要是對 IDE、plugin、build tools 有利，不用每個測試框架做一套自己的工具。
當然，真的看完 JUnit Jupiter 而產生了愛的話， JUnit Platform 還是可以當 Migration 過程的平台（從 JUnit 4 到 JUnit Jupiter，或者是從 TestNG 到 JUnit Jupiter？）
目前的理解是這樣…
龍麟有規則性、龍身是貝茲曲線、龍頭有對稱性…簡單來說，龍適合用程式來建模，其實可以更細緻，只是我想驗證一下想的對不對而已。
跟貝茲曲面或 Torus knot 之類的建模相比，龍算是簡單的，只是比較有噱頭…XD
Every time you create either a FileInputStream or a FileOutputStream you are creating an object, even if you close it correctly and promptly, it will be put into a special category that only gets cleaned up when the garbage collector does a full GC.
就算自己 close 了也不是真的 close 了？還是得依賴 Full GC 呼叫 finalize 才會真的 close？有所謂的 a special category？
public void close() throws IOException {
synchronized (closeLock) {
if (closed) {
return;
}
closed = true;
}
if (channel != null) {
channel.close();
}
fd.closeAll(new Closeable() {
public void close() throws IOException {
close0();
}
});
}
protected void finalize() throws IOException {
if ((fd != null) && (fd != FileDescriptor.in)) {
/* if fd is shared, the references in FileDescriptor
* will ensure that finalizer is only called when
* safe to do so. All references using the fd have
* become unreachable. We can call close()
*/
close();
}
}
如果他的意思是因為 override 了 finalize，所以會被排入 GC 時得呼叫 finalize，那也很奇怪， finalize 一直都在那啊？還是說他的意思是，finalize 裡寫的程式碼檢查會造成不必要的開銷？
去看看別的地方的 comments，也有人覺得這說法不太對。
從過去一年多來的 OpenSCAD 作品，抽取了一些模組與函式建了個程式庫，如果對程式建模有興趣，使用這程式庫應該可以省不少功夫。
比方說你想盤個什麼，archimedean_spiral 函式可以直接給你必要的點座標與角度，你不用去導螺線的相關公式 …
就原討論來看，跟 Functional programming 比較沒有關係，感覺只是想設計 Method chain 的問題，也就是將 if 判斷從程式碼中去除，或說是隱藏至 API 中。
如果真要跟 Functional programming 有關係，那麼就得考量像 filterElse、mapElse、reduceElse 之類的 API，因為每個人在迴圈中做的事不同，而且 xxxElse 可以指定的兩個任務必須是相同性質。
例如 filterElse 的話，兩個任務都要是 filter，而不能像是去做得到單一值的任務，或者是去做了 map 的動作，也就是像（也許還得加上 p1、p2、p3 這類判斷條件）：
source.filterElse(p1, a, b) // a 、b都是filter，只是filter條件不同
.mapElse(p2, c, d) // c、d都是map，只是map方式不同
.reduceElse(p3, e, f); // e、f都是 reduce，只是reduce方式不同
原討論舉 foreachElse 容易讓人誤會，因為 Java 8 中 foreach 的本質就是 imperative 的。
至於 while 或 for 要不要搭 else，那太容易造成誤會，Python 中雖然有，一直以來也不建議使用，有人說那是因為 else 只會在迴圈中沒有 break 時執行，不過，改成 else 會在迴圈中有 break 時執行，或者是 else 只有在迴圈沒有執行時執行，我想都會有人有話說。