TechTalk 專訪 Episode 26 逐字稿 - Java 8(下) by TechTalk@TW | CodeData
top

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)

分享:
按讚!加入 CodeData Facebook 粉絲群

相關文章

留言

留言請先。還沒帳號註冊也可以使用FacebookGoogle+登錄留言

熱門論壇文章

熱門技術文章