JEP 12: Preview Language and VM Features1
看來是會變動，要開 --enable-preview 才能用的語法。
個人也對 preview 這件事還沒搞懂 然後原本的 string multiline literal 也從 preview 先拔掉了ＸＤ
Switch expressions is a preview language feature. This essentially means that even though it is complete, it has a possibility of not being confirmed as a permanent feature in a future Java release. This happens for a reason. Java 12 and IntelliJ IDEA1
我在想這是不是和 parser 比較好寫比較有關？尤其是在需要支援 type inference 的條件下
寫久了都會習慣的，可以順順的切換，不要小看人的適應能力啊！這也比說多國語言簡單許多。
kotlin 因為要和 java 互通所以選擇了捷徑 untagged unions
Swift 雖然要和 objective c 互通但仍然選擇了 taggged union
結果是？
Swift 超難用
T?? 這種兩層的處理起來很煩，不好 debug，compiler 和 IDE 都笨笨的也不會顯示清楚一點。試試處理 json 就知道了 (json 通常會有好幾層 Dictionary，每一層都會遇到一次 nil)
Kotlin 的做法實用多了，遇到 optional 你就很直覺解 ? 就好了，管他是幾層。
Kotlin 寫起來會有一種順暢的感覺，就是在這種小地方比較 務實。每個小角落都處理的很順，整體累積下來就是寫得爽，你不會有花時間跟它的 type 在對抗的感覺。
Java 9 廢棄了 finalize 方法，FileInputStream 等也清空了 finalize 方法的實作，改用 PhantomReference 的機制，JVM 有個執行緒會監控 Reference，在實例不再被參考時，呼叫 close 方法。
至於相容性的部份，若有 FileInputStream 的子類，且自定義了 close 方法，實例化時會有個 AltFinalizer 產生，AltFinalizer 建立時會包裹 FileInputStream，AltFinalizer 的作用就是等著被回收時，呼叫自定義的 finalize 方法（被加了 @SuppressWarnings("deprecation")），其中呼叫了 FileInputStream 的 close 方法。
繞來繞去的 ...
ES 坑真的有人跳耶... 一種 J2EE 的即視感.
Event Sourcing 和 Micro service 這類架構都不是一開始就該去選的, 無論你系統多麼的新, 想做多大多肥.
而是你開發到後來發現某個部份有一個很難解的問題, 然後剛好這類特殊的架構可以解決你的痛點, 這時候才會開始評估 (還不見得要用咧