變天了！
value type 改名 InlineType , InlineType 不能 null，要多一層 IndirectType才行 (後面加個 ?)
IndirectType 白話講就是 Boxed Type 吧
primitive 和 boxed type:
int -> Integer
到了 inline 和 indirect 就會寫成這樣
inline class Foo
Foo -> Foo?
所以 inline type 可直接當 primitive 來看，像這種寫法 List<Foo> 是不行的，你得用 indirect type (即Boxed)，也就是 List<Foo?>。
私以為這個設計高竿，只用一個 symbo ? 直接解決原本 value type 模菱兩可的表示 (看不出到底有沒有 boxing)，而這個 ? 可以為了之後的 nullable type 舖路
Boring Tech 的特徵:
- 有 LTS 版本，時間長達三年以上
- 即使沒有明確的 LTS，舊版本也繼續維護到天荒地老
資訊新人都以為學最新最潮的技術是最棒的投資，卻不知道 Boring Tech 學完一用就是十年...
舉例問一個寫 nodejs 的，給他選 SQL 和 GraphQL，他會選哪個？
Internal iteration並沒有如傳統iteration有next()用來指示走訪下一個元素的方法。Internal iteration由你的應用程式決定要被迭代的集合，但該如何走訪集合中的的每一個元素則是由JDK決定；而External iteration則是被迭代的集合及迭代的方式兩者皆由應用程式來決定。
而主要的差別是，External iteration只能以序列方式(serial)迭代集合，而Internal iteration除了可以序列方式，也支援以平行方式(parallel)來迭代集合。
也就是說Sream的forEach可以利用平行計算將迭代的程式拆分為多個子程式來平行處理，最後在將子程式的執行結果組合起來。其意味著Stream的forEach比原本的iteration更彈性且高效
聽起來是個從 iteration 改用 stream 的好處
通常 second level cache 可做的事都會在更前面擋掉 (例如網頁的 cache) 所以 2nd cache 沒事不用去碰，用比較宏觀的角度去最佳化比較好
在通常情況下會將具有以下特徵的資料放入到二級快取中：
- 很少被修改的資料。
- 不是很重要的資料，允許出現偶爾併發的資料。
- 不會被併發訪問的資料。
- 常量資料。
- 不會被第三方修改的資料
而對於具有以下特徵的資料則不適合放在二級快取中：
- 經常被修改的資料。
- 財務資料，絕對不允許出現併發。
- 與其他應用共享的資料。
在這裡特別要注意的是對放入快取中的資料不能有第三方的應用對資料進行更改（其中也包括在自己程式中使用其他方式進行資料的修改，例如，JDBC），因為那樣Hibernate將不會知道資料已經被修改，也就無法保證快取中的資料與資料庫中資料的一致性。
雖然很早就知道有二級快取這功能，但考慮到以下項目，所以都沒有機會用：
- 資料一致性的問題
- 與其下多個 SQL 然後 cache 起來，不如下一個 SQL 就把多筆資料都撈回來應該還比較有效率
這是三件事。跟 JRE 用什麼編碼無關，JRE 的編碼頂多影響到 runtime 字集的大小。傳輸時只要二個 socket 有一致就好了。顯示歸顯示，不過顯示也可以看成一種傳輸，terminal 的好處是，它預期的編碼方式可以在 runtime 調整。這個 case 是顯示部分不一致，調整 terminal 或自己程式輸出的編碼都可以。