TechTalk 專訪 Episode 26 逐字稿 - Java 8（下）

TechTalk 專訪 Episode 26 逐字稿 – Java 8（上） << 前情

HC：ok，良葛格，所以像另外一個比較大的改變就是Data Time API 嗎？那其實你剛剛已經也提到蠻多了。

C：是。

HC：那你還有沒有什麼要補充，你覺得這個 DateTime API 對 Java 開發人員，會有哪些其他影響？

C：一開始其實有稍微談到一些 DateTime，我有講過，你要使用 DateTime API，就跟一開始要使用 Joda-Time API 一樣，你得認清楚 Joda-Time 或 DateTime 把時間抽象化成哪一些類別、哪一些介面，然後才知道要怎麼去使用、去操作它，也就是說，API 強迫你要去認識時間的觀念，一開始我是舉一年的毫秒數為例，其實就是在強調，有些些基本的時間觀念要去瞭解。
C：我自己在寫《Java SE8 技術手冊》的時候，我曾經想過要不要把那些時間基本觀念寫出來，因為就一個 Java 開發者，他如果是很 Busy 的開發者，可能只急著要使用 API，我後來想了很久，還是決定把那寫出來。例如，什麼叫做 UTC、什麼叫做 GMT，其實大部份人一直以為 GMT 等於 UTC 這個部份就是錯的，GMT 其實在某個時間點之後就不再等於 UTC 了；或者說談到改曆的問題，或者是潤秒的問題，有些開發者不知道有潤秒問題…我還是決定先把這些時間觀念介紹出來，也就是說，這些基本觀念要認識。還有像是時區以及偏移量的問題，譬如說美國有四個時區、中國只有一個時區，這一類的問題大家都要去認識，因此當你想要從這邊計算美國的時間，或者從這邊計算中國大陸的時間之時，其實不是說你換個偏移量就好了這等等的問題。
C：一開始就提到毫秒數，那這個毫秒數怎麼來的？我們現在系統時間都是用毫秒數，也就是 1970 年 1 月 1 日至今的毫秒差，這個其實是機器計算的時間，每台電腦在計算時間的話有一個基準點，大概就是這樣計算時間，毫秒數是一串數字，對人沒有意義，對人有意義的叫做幾分幾秒幾毫秒，幾年幾月幾日這個叫做人的時間，在探討 Joda-Time 跟 DateTime 的時候這一點非常的重要，而且其實你進一步去想，在設計時間相關的介面的時候，也要去區分。ingramchen有寫過 DateTime 的一篇文件，裡面就有探討到，什麼時候要用機器時間，什麼時候要用人的時間。
C：剛好那時我也有遇到一些時間相關問題。教育訓練上有遇到，有人問過我日光節約時間的問題，什麼叫日光節約時間？其實現在台灣很多開發者不知道台灣實施過日光節約時間，如果你說美國那大家可能知道，那台灣的話大家就不知道，為什麼會扯到日光節約時間，我舉個例子，如果有一年不是潤年，而你請使用者輸入一個日期，結果他輸入了 2 月 29 日，也許你的 API 或者你本身知道 2 月 29 日在該年不存在，你會對他提出警告，因為大家都比較知道潤年的問題，那以兩位的話，你們覺得要不要對他提出警告？

MY：老實說，那個日光節約是真的是蠻久以前的，我也不知道。台灣有實施過這件事情。

C：是。

HC：這小時候有提有一次。

C：對。

HC：好像時間要提早一個小時。

C：是。

MY：我都沒印象。

C：對，那比如說，我們先不要講日光節約時間，我們就講潤年好了。如果那一年不是潤年，結果有個使用者要輸入 2 月 29 號，那你要怎麼處理？

HC：應該是要提出警告。

MY：應該是要擋掉。

C：對！要擋掉對不對？ok，因為怎麼樣？你知道那一年不該有2月29日對不對？

MY：對。

C：因為你知道對不對？你知道這件事，ok，好，那我再問各位一個問題，台灣時間 1975 年 3 月 31 日，那一晚 11 點 59 分 59 秒，下一秒是不是應該 4 月 1 號 0 分 0 秒？

MY：對！

C：大部份人可能會這麼覺得。

MY：理論上，對。

C：理論上對不對？

MY：沒錯。

C：但是沒有，如果你用 Date、Calendar 計算，下一個時間就是 4 月 1 號 1 點 0 分 0 秒。

MY：日光節約時間？

C：是，因為當年台灣有實施過日光節約時間，好！你不知道對不對？

MY：不知道。

C：假設你不是用 Date、Calendar去計算，而是有一個使用者進行輸入，也許是保險業務員，總是有那個時間出生的被保險人對不對？那你要輸入時間，可能他就是要把時間設成 4 月 1 日 0 點 0 分 0 秒，也許是他輸入 1975 年 4 月 1 日，那後面的時間由你設計的 API，直接補齊 0 點 0 分 0 秒！那請問你，這是對的還是錯的？

MY：如果一定要輸入那個時間是不是？可是並沒有那個時間是不是？

C：不是一定要或不一定要，而是說如果有業務員進行輸入，或者是你當初在設計 API 時允許設定 4 月 1 日 0 點 0 分 0 秒這類動作，那你覺得這個動作，算是對的還是錯的？

MY：也是有問題嗎？應該是要寫日光節約時間？

C：我曾經在 iThome 寫了一篇文章，就是〈機器時間觀與人的時間觀〉談到這點，其實剛的問題不算對也不算錯，因為這個就是你的時間觀跟我的時間觀的問題，ok，因為其實大部份人不知道日光節約時間，那這一個一小時差你有沒有 care，你的客戶不知道、你也不知道，那也許就沒有問題，就是說你可以真的儲存 4 月 1 日 0 點 0 分 0 秒，因為大部份人也不會特別去計算那 1 個小時的差別對不對？
C：如果一開始你的客戶跟你在設計的時候，是允許 4 月 1 日 0 點 0 分 0 秒，萬一假使有一天，來了一個開發者，他知道有日光節約時間，他就說當初怎麼可以允許這麼做？那就表示他的時間觀跟你們當初的時間觀不一樣了，這個意思就是說，其實我們在思考時間的時候，大家的時間觀要一致，今天如果假設我們這個系統，就是完全不考慮日光節約時間，那這個部份就是應該規範下來，如果我們這個系統在設計的時候，該考慮日光節約時間，那像 4 月 1 日 0 點 0分 0 秒就應該擋下來，應該擋下來這樣子，這就是時間觀要一致，不要你覺得要考慮日光節約時間，而我覺得不用，這種時間觀不一致就會造成問題。

MY：要統一就對了？

C：對，機器的時間觀就是一個時間軸連續毫秒數對不對？機器時間觀比較沒有問題，會複雜的是人的時間觀。為什麼我們要認識 Joda-Time、DateTime 的時候，要去先瞭解時間的基本觀念？你得瞭解時區、瞭解偏移量、瞭解政治、甚至瞭解歷史，因為有改曆的問題，因為這個是什麼？這是人的時間觀！假設談到歷史上的時間跟你知道的歷史上的時間不一樣，那也許是我知道歷史上有個改曆時間而造成偏差，這叫做人的時間觀。
C：複雜的都是人的時間觀，後來我個人是覺得，在人的時間觀上最重要的，就是取得一致的時間觀，那聽起來好像很哲學上的一個觀點，但是事實上還真的蠻重要的。例如，2 月 29 日這個時間，因為你知道、我知道，你的時間觀跟我一致，你就不會覺得有疑慮，我也不會覺得有疑慮，大家都覺得應該擋下來；日光節約時間你知道，但我不知道，那有人就會覺得要擋，有人就會覺得不擋，就是我們時間觀不一致。時間觀不一致就會使得政治、歷史、地理那一些時間的複雜因素摻雜進來，到最後大家會吵，
C：ok，如果就設計上，ingramchen 有寫過那一篇文章，我在留言上問了一個問題，像這個時間他會怎麼處理？他說如果是這樣的話他應該會擋下來，但是像這種由人輸入時間你不要讓使用者自由格式輸入，我覺得這一點給了我蠻大的啟發。比如說是一個網頁，你希望使用者輸入生日或者是輸入比較詳細的時間時，你要提供的使用者界面，可能就要事先考慮到要要採用哪一個時間觀，如果我有日光節約時間的考慮、有用改曆的考慮等，這個部份可以用個 DateTime Picker 讓他去選日期時間，而那個 DateTime Picker 是正確地反映我的時間觀，這樣就是正確的，它會去幫我顯示存在的時間，讓使用者去點選輸入，那使用者的時間觀就是人的時間觀，人的時間觀就不要讓他存你覺得不存在的時間，我覺得這是一個蠻重要的考量。
C：你不要做一個文字欄位讓使用者輸入時間，因為了不起你用一個 Regular Expression 來判定格式對不對，但是格式對不代表那個時間存在，不如用一個 DateTime Picker 讓他去選你的時間觀裡面認為存在的時間。
C：簡單的一句話就是說其實，這類 API 標準化之後，會強迫我們去思考更多的問題，很多過去被我們單純化的問題，因為這個東西的加入，迫使我們必須去認識它們，這類 API 對開發人員的影響是在哪？知道我們以前有多忽視這類議題。

HC：ok，好，良葛格剛才你介紹那麼多 Java 8 新功能，那你覺得現在是升級到 Java 8 的好時機嗎？

C：升級問題的話，其實我覺要分幾個討論，當然政治性問題的話，真的還蠻多可以考慮的，政治性的問題舉個例子來說，如果在一間保守的公司，多是 JDK6、JDK7，你敢冒然就要升級 Java 8 嗎？這當然是很多問題要考量。
C：我們就撇除那個部份不談，我們來談功能上的問題。舉個例子來講，上星期我去做 Python教育訓練，不過因為我的上課原則是，學生任何問題都可以問，結果他拿 Java 的問題來問我。

MY：是這樣，所以他來上 Python 的課，然後問 Java 的問題？

C：對！因為他在看我的《Java Tutorial》文件，那天問到 Gradle 的操作，因為我那個《Java Tutorial》文件是用 Gradle 去 Build。

MY：ok、ok。

C：他 RUN 不出來，而且只是一個基本的 WEB 應用程式，我就看它的 Exception 是 ClassFormatException，很簡單，因為我的 Gradle 下的 DEPENDENCY，Tomcat 是 7.x 的。他 build 不出來，我就問說你的 JDK 是哪一版的？是不是 8 的版本？他就說對，我確認一下真的是 JDK 8，他在 JDK 8 上運行 Gradle，但是它沒有修改 build.gradle 中的 Dependency。
C：當然大家可能覺得這很單純，好像只是 JVM 換一下，JVM 保證向後相容對不對？其實也沒那麼簡單，因為 Class 版本的問題，你的平台一定是相依在某個 JDK 版本，那你的 JDK 版本如果像這個遇到 Class 類別格式版本的問題，它就有可能不認得新格式。例如要做一些動態載入類別的動作，就有可能出錯。所以，在功能上來講，升級要考慮的問題還蠻多的，就是說，你要懂道你的專案，像我看到他那個 ClassFormatException我就知道，因為這個練習西是我設計的，我知道 ClassFormatException，我知道我的 Tomcat 用哪個版本，我知道我用了哪些程式庫，所以我遇到這個問題，馬上就知道應該是程式庫載入類別檔案的問題。
C：也就是說，其實你問，就功能上來講，是不是適合升級到 JDK 8？第一你要瞭解你的專案、使用的平台、相依在哪些東西上等，你要去調查一下這些相應的程式庫平台，有沒有開始在 Support Java 8 了，至少我的 Dependency 的例子，我第一個要瞭解的，一定是 Tomcat 有沒有支援 JDK8 的版本，這些就是要去做一些瞭解跟調查。
C：ingramchen 有寫過一篇，將 15 萬行的專案升級，其實他有一些東西要去 Follow，因為如果說你一開始東拉一堆程式庫、西拉一堆程式庫，在升級上一定會困難重重，15 萬行他有講一些條件就是說，因而在符合條件下升級會是比較順利的，所以你說升不升級，功能上也是考慮上蠻多的，就這一點的話，我會覺得比較再慢一點升級，至少相關的程式庫或像容器這一類的東西，要等他們能夠支援，例如說 IDE 也是，JDK8 出來 NetBean 就有支援了，但你總是 Eclippse 等 IDE 或 plugin 昇級對不對？

HC：就是慢了一點點。

C：當然我會覺得，一般東西都是這樣，等個半年一年後，你總是要等他 update X 出來，穩定一點會比較好，如果真的是要一個上線的版本，還有平台的問題、程式庫的問題、工具的問題。所以講句難聽一點的話，現在功能上不是升級的一個時間點，一般接受的時間國外比較快一點，但是台灣的話，總是會慢個一兩年、甚至兩三年。除非你的案子真的沒有那些相依性的問題，那當然就升級。
C：再從另外一個角度來講，如果不考慮政治或功能問題的話，目前 JDK8 在社群的接受度跟討論度還蠻高的，跟JDK 7 比起來，實在是差差太多了。

HC：JDK 7 的問題是，它沒有什麼很吸引人的升級的。

C：因為他是就是政治性的版本，Oracle 吃下 Sun，總是要先安撫一下人心，在我的書裡面也有很直接寫出來，那就是政治性目的高於功能性目的的一個版本。那時我在改版，我就想說我要改版什麼？因為我不知道要改什麼，你知道嗎？

HC：其實我真的覺得，對啊，他就是那幾個小功能。

C：對。

C：後來我只好整本書重寫，我想說，我沒有辦法在功能上改版，那我整本書在敘述上改版。

HC：是 7 那一版還是 8 這一版？7 那本是重寫？

C：6 到 7 那一本是重寫，7 到 8 的話，是以加入一些 Lambda 跟 DateTime API 為主角，其他大概 6 成是重寫或更新範例程式碼；6 到 7 是整本重寫，因為我想說，功能性它們沒什麼著墨點，那我就是說，好吧！我把我過去一些經驗整個再寫進書裡面，我功能性上沒辦法重寫我的書，那經驗上可以重寫吧！不這樣子會對不起讀者！

HC：ok 了啦。

C：回過頭來就是說，其實 7 真的是一個政治性版本，不過也不能說 7 沒有作用，因為其實 7 當初就是被切成一半。

HC：對。規格被切割了。

C：對，其實 Stream API 在 parallel 的份，其實底層就是 Fork-Join。

HC：Fork-Join 是 7。

C：對，我們很少直接寫 Fork-Join，因為 Fork-Join 也不好寫，要會切除相依性不容易，那 8 出來，寫 parallel 那個部份的話會比較好寫，至少你不用自己去 Fork-Join，社群的接受度還蠻高的，討論的點還蠻多的，至少就這半年多來，Java 感覺有點起死回生這樣子。

C：有點討論熱度。

HC：對對對對對對，已經有點不太一樣了。

C：確實有點不太一樣了，其實 7 出來沒有什麼人要升級，但是 8 的話，其實還看到一些人會說，他會想嘗試、他會想升級、他正在評估，對，你說要不要升級那是一回事，但是其實可以先想想，要不要評估，現在倒是值得開始評估。

HC：沒錯。

C：我是這樣子覺得，值得開始評估了，評估完之後，當它穩定到一個點，程式庫、平台、工具都已經上來了，你就隨時可以做升級這樣的動作。

HC：瞭解。

MY：瞭解。

C：是。

HC：我們剛剛在講說，其實前幾年的 Java 基本上完全沒有什麼人要注意的那種感覺，就是他也沒有什麼新東西，然後也沒有什麼太令人感到興奮，當然 Lambda 大家覺得不錯，但是因為實在是拖很久，所以我覺得前幾年比較常聽到的一個說法就是說，大家覺得說 Java 已經死了，我們應該要比較關注的是 JVM 這個平台，就是在這平台上面寫可以 Run 的東西，你覺得你贊同這樣的說法嗎？你有什麼樣的想法？

C：你要我老實說，Sun 真的是那幾年正在走下坡，再來又被 Oracle 吃下來，再來又跟 Google 打官司。

MY：Google 官司，對。

C：那幾年在政治上很熱鬧，那在技術上 Java 有沒有什麼點？沒有！當然，Java 現在號稱九百萬多開發者，這塊餅大家要不要吃？大家當然要吃，所以就找個見縫插針的說法，就是 JVM 平台比 Java 語言來得重要，如果真的被這說法插針成功了，那天下就是它的，所以這樣的說法，對於 Java.next，也就是所謂的下一代 Java 語言，或說下一個取代 Java 的語言，其實是蠻重要的，不過實際上，不知道你們有沒有寫過 Jython、JRuby 或是在 JVM 上寫 JavaScript這類的東西？

HC：我們有比較用一點 Groovy。

C： Groovy 算是還比較跟 JVM 緊密結合的。

HC：對。

C：Groovy 就是真的為了 JVM 而生，那那沒話講，但是就其他語言來講的話，你總是還要做一件事情，你要懂Java對不對？你為什麼會想要在 JVM 上 Run？跨平台嗎？不可能，現在很多語言是直譯的程式，就算是編譯式的，其實有很多平台版本，只要與 Follow 一些 Standard 的作法，就功能上你還是跨越了平台，不會純綷為了跨平台在 JVM 上 Run JavaScript。

MY：是。

HC：不過像 JRuby 是為了效能，我知道有些人在 JRuby 是為了效能。

C：對，是為了效能沒有錯。

HC：對對，所以其實有些不太一樣。

C：有些人是為了效能，對，那效能的話，你還是有一些部份需要認識 Java 的東西。

HC：對。

C：你的東西終究還是 Run 在 JVM 上面，你用的記憶體元素，一些計算什麼的還是 Run 在 Java 上面，如果要再進一步去複製 Java 生態系的一些東西那就更複雜了，你還是要去認識原來 Java 裡面有什麼，簡單地來講，你在 JVM 上 Run 其他的語言，要真正用深一點的時候，你還是回頭要去認識 Java。
C：這邊講的 Java 是 Java 語言本身，我覺得天下還是沒有白吃的午餐，觀察了這麼久，Scala、JRuby 等或者甚至是 JavaScript 這些程式語言所謂的優勢，也就是說試圖瓜分掉 Java 生態系的一塊餅的這些東西，你真的要在 JVM 上 Run 它們，還是要去認識 Java 本身。
C：我覺得平台會不會比語言還重要，將來不保證，有一本書《程式設計師提升生產力秘笈》，其中有講到一句話：「語言終究有一天，會被自己的重量給壓垮」Java 這部份，當然有一天絕對會被重量給壓垮，但是就是說就目前來講，或許是 JDK8 加 Lambda 進來，大家還蠻有興趣的，所以目前來講，Java.next 的語言，目前還沒有一個 killer 出現，所以目前 JVM 平台比 Java 語言還來的重要這一點，還不是它出現的適當時候。不論是 Groovy、Scala，或者是強調 Functional Programming 元素更多的 Closure 等語言，目前來講都沒有足以取代的優勢。

MY：ok，那 Google 與 Oracle 為了 Java 的專利鬧得不可開交，你認為說 GAE 與 Android 等平台，未來會實現 Java 8 的新功能嗎？如果最大的 SAAS 平台與 Java 8 對立，對 Java 社群會不會是又是另一種分裂？

C：其實這個東西是商業競爭的問題，那商業的東西就是由政治與利益來決定，天下沒有永遠的敵人，也沒有永遠的合作夥伴，這是大家都知道，那 IBM 都可以跟 Apple 合作了對不對？

HC：對，最近的新聞還蠻神奇的。

C：N年前根本就是不是你死我亡的兩公司，N 年後竟然合作了，那你覺得呢？你說真要去預測，商業競爭的東西很難講，如果你真的要問我，因為畢竟問題提出來，那我的想法是這樣，就像剛剛講的， IBM 跟 Apple 都能合作了，還有就是例如說 Microsoft 的 Azure 都可以支援 Java 了，那 GAE、Android 未來有什麼理由不支援？或者是支不支援到 Java 8？Android、GAE 為什麼要一開始就使用或支援 Java？雖然 GAE 一開始是 Python 為主，後來馬上就有 Java 的語言，因為 Java 的開發者多，多就有利益，有利益為什麼不賺？有錢為什麼不賺？
C：假設有一天，Oracle 真的贏了官司，Google 得賠巨額的錢，他們不爽了，真的不想支援了，那 Google 會不會就完全拿掉 Java 的部份，我覺得也不太可能，除非 Oracle 直接下禁令，不過我覺得這個法律上可能也沒有辦法。

C： Google 完全就不能用任何有關 Java 的語言，Java的東西應該是不可能，我覺得記得 Java 一開始沒有這種法律規定，他們的爭議主要是在 API 的版權。

HC：對。

C：對，所以你說他會不會不支援？我覺得不太可能，之後會不會整個換掉，用另外一門語言？如果是 Apple 的 Objective-C 我覺得有可能，因為 Apple 比較封閉。

MY：不一樣在哪？

C：Apple 只要強迫 APP 開發者換就好了，APP 這種東西偏前端，前端的東西就是這樣，界面一換，大家就全部跟著換，那個 SDK 一換大家也就跟著換，因為 APP 生命週期比較短，所以 Apple 可以做這個動作，他可以在某個時間點把 Objective-C 換成 Swift，他們真要耍手段是做的到，不過我不覺得 Apple 會一次性、破壞性地做這件事，畢竟開發者還是不能隨意冒犯。
C：那回來 GAE 這個部份，在商業上完全絕裂的話，Google 有可能推自己專屬的語言，讓它成為 GAE 或 Android 平台上比較親切的語言，譬如說你用 GO 語言，我可以提供更多方便的API，用我自家的語言會比較友善一點，那用其他語言稍微不友善一點，會不會這麼做？可能會這麼做。但是你說 Java 社群會不會分裂？會分裂的不是 Java 社群，會分裂的是 GAE 跟 Android 社群，他會變成就是說，我要寫 GAE 或 Android 時，我要選 Google 自家語言還是選我所熟悉的Java語言？就只是這樣而已。
C：Java 社群會不會分裂？分裂的話就是我在 Java 這一塊上自創一個語法，我覺得法律上不可能，所以 Java 社群不會分裂，你真的自創了一個 Java 語法，開發者也不見得買單，因為畢竟 Java 開發者這麼多，我寫了一個語法只有我這個平台上能 Run，那其他平台不能 Run，就會有溝通的問題。所以會分裂的應該是不是 Java 社群，是他們本身平台的社群。

HC：ok，良葛格你剛其實提到的就是說，你一直都在網路上發表很多這種技術相關的的文件。

C：是。

HC：其實也是很多人會自學，不管是 Java 或是 Python，那可以稍微分享一下學習這些、這麼多新技術的訣竅嗎？

C：其實我算是有點轉轉換跑道，算算時間這一個禮拜應該會有篇 iThome 的文章會刊出來，講到我轉換跑道的一個過程。那我轉換跑道的一個過程中，我強迫自己寫東西，因為我發現我看完資料後記不起來，所以就變成我就是寫下來，才會比較踏實，大概從 2003 年開始寫，當年沒有什麼，連「部落格」這個名詞都沒有出來，後來部落格興起，開發者也蠻多去寫部落格的，然後後來慢慢的有一些聲音，叫做優秀開發者的特質之一是技術寫作，我就覺得有一種很驚喜的感覺，好像在講我…XD

MY：剛好這樣子。

C：對，然後其實這個聲音還蠻多的，優秀開發者的特質之一是技術寫作，這個部份著墨很多，什麼牽涉到表達、組織能力、邏輯能力、溝通能力的，那個大家都看很多了，對，所以我覺得我算是矇到，一開始矇到一個點，就技術寫作這個部份，確實在學東西上非常有幫助，至於其他附加的部份，怎麼樣跟人家交流，當然也有，就學習上，技術寫作真的蠻有用的。
C：另外就是說挑戰式的寫作，譬如說我會設定一個目標，我對他不熟但是我對他有興趣，例如說 Docker 好了，最近很紅，我對虛擬化其實不專精，但是我就會想說，我設定一個目標，我要完成這個目標，那中間可能需要查網路、可能需要看文件，可能需要很多 try and error，然後就是把那個目標完成，就是說，我自己設定問題，我自己去挑戰，挑戰式的寫作就是說逼著自己去認識一個新的東西。
C：甚至有時候，還會去認識 Y-Combinator 之類的，就因為他出現在我的眼前太多次了，我會想說，那到底是什麼東西，我會好奇，我會去想要弄懂他，就基於好奇心讓我去研究他，就像我剛剛講的。過去有一陣子 Scala 出來很流行，然後大家就會去討論到 Functional Programming，然後有一陣子 Ruby 流行，又有人去討論到 Functional Programming 了，有一陣子又有人在 Python 上實現 Functional Programming，我就想說這到底是什麼東西，於是好幾年前，我就開始研究它，那時候沒什麼用，直到 Java 8 裡面導入那麼多，連那個 Monad 的概念都導入了，我就覺得真的，好像撿到一樣。我就會說，有時候人家會覺得冷門的知識，如果你有好奇心你就去研究他，有時候你就是這樣子。選一個很熱門的知識，誰曉得它幾年後不紅了？有時候，你就是無心插柳選了一個冷門。
C：幾年前還算冷門的知識，結果現在 Java 8 有這麼多 FP 的元素，我就覺得還蠻有趣的，有時候，我都想說，如果我沒有那麼早去研究那些東西，我現在就不會撿到一個大便宜，搞不好現在有些 Java 書的作者，還在想拚了命想瞭解 Lambda，雖然你可以寫語法，你可以抄範例，但是可能就沒有辦法寫出什麼 FP 的概念。
C：技術寫作、挑戰式的寫作，然後解決學員實務上問題的經驗、然後好奇心，就算對象是一個很冷門、人家所謂的豆知識，豆子一般的冷門知識也沒有關係，你就去研究他，基於你的興趣，你覺得有趣的東西就去 Run、就去學，跟 JavaScript 一樣，誰曉得他會翻身？

MY：好，良葛格我們準備的問題差不多了，你還有什麼就是想要補充的嗎？

C：Java 8 高階排序 API 的部份，我覺得大家也可以重視一下，因為其實大家還蠻去常處理排序的，以前大部份就是開發者自己寫那些東西。guava-libraries 裡面有高階排序API，這部份在 JDK8 裡也有些現成的東西，你可以用那個比較流暢的方式去組合排序規則，組合出你想要的排序方式，這部份大家可以去研究一下，我覺得蠻有價值的。
C：另外一個部份我覺得還蠻有趣的就是，如果你裝好 JDK8，就會有個 Nashorn，也就是你裝完之後，JDK8 的 bin 目錄有個 jjs 指令，可以讓你 Run JavaScript 的，剛剛有討論 VM 平台比語言來的重要的議題，一些主流重要語言能 Run 在 JVM 平台上是很重要，JavaScript 現在蠻有發展趨勢，我想說 JDK 內建的這一個 jjs，我覺得有點令人期待，因為一方面我對 JavaScript 還算是熟，我會想大家可以去瞭解一下這個內建的 JavaScript 引擎，大家以前比較熟可能是 Rhino，它很舊了，現在有個新的 Nashorn，而且看他的文件，他將來還有意思繼續往後支援到 JavaScript 下個版本 ES6，現在是支援到 ES5，不知道這樣子是否能在 JVM 的生態上，發展出一個類似 Node.js 的產物，我是覺得有可能，大家可以去瞭解一下，畢竟能夠善用 Java 生態系，而且現在大家幾乎都有懂JavaScript的情況下，這個東西我覺得還蠻有趣的，值得期待。

HC：ok，好，那不好意思因為時間關係，沒有辦法聊完所有準備的內容，那希望下次有機會的話，可以再邀請良葛格來分享其他的議題。

C：是是。

HC：也很高興能夠百忙之中抽空接受我們的訪問。

C：不會，大家比較辛苦。

MY：謝謝良葛格。

HC：那我預告一下，難得我在這一次訪問可以敲定下一次的主題，就是下一次我們預定要訪問的主題是 Linux Container。那今天訪問到這邊告一個段落，那謝謝良葛格，也謝謝大家的收聽，感謝。

C：謝謝，拜拜。

MY：拜拜。

後續 >> TechTalk 專訪 Episode 27 逐字稿 – Linux Container (LXC)