2006 JavaTwo Day two
呼~~ 今天最後 google 的兩場真是太刺激了，簡直是 scjp 的大會考，puzzle 的題目真的會讓人腦汁沸騰兼冒泡。第一場的題目我幾乎全錯，反到是第二場因為是局限在 jdk5 而比較好猜。雖然個人過去對 puzzler 的實用性抱一些疑問，但每一題的背後都有一些實用性的建議，該怎麼寫才能避免什麼什麼的，等於是小型的 effective java 了。印象最深的是 jdk5 的 list.remove(int) 和 Arrays.asList(int[])，這兩個真的把我嚇呆了。想想 jdk5 帶來的 varargs 和autoboxing 真的是雙刃劍，優點是不少，但也 break 了一些 API，使用時又得小心易易的... 我想唯一的解法還是多寫 unit test，這樣才能確保正確的運用 api，而且就算有 bug 找起來也快一點。總結來說 Neal 和 Joshua 這兩天下來的場次都很實用，講演也很活潑 (哈，還穿那個水管裝耍耍寶！)，世界級的就是世界級的啦！啪啪啪~~~
再來本土的也有不錯的啦，Tempo 版主的 DWR 上完後真的讓我躍躍欲試，最近剛好有要寫 chat 的網頁，reverse AJAX (comet) 這東西正好可以派上用場。雖然 Wicket 現在還沒有支援 comet (計劃中)，不過 Wicket 的網頁都是純 HTML，愛加啥就加啥，所以配上 dwr 完全沒有問題。這幾天就來試試，透過 Tempo 的演講應該可以縮短不少自己摸索的時間吧！
剩下的... 我聽了朱仲傑的 AJAX 完全攻略，可惜的是大部份的東西我都已經知道了，而且沒有提到一些實作的經驗談真的是蠻可惜的... 第一場則是挑了 JBoss cache，王文彬先生花了不少時間做一些名詞解釋和功能分類，講到後來主題好像有點鬆散，不知是要強調什麼... 最後面的 PojoCache 的實例和benchmark 才拉了回來。cache 本身就是用在read-mostly 的資料，因此能套用 PojoCache 的 pojo 大概也只會改一小部份的資料而已。這種 pojo 如果 replicate 時要 copy 全部的 state 真的是太浪費了，這時候 PojoCache 這個 fine-grain replicate 的技術剛好就能發揮最大的功能。Ben 所展示的片段程式碼中還是得呼叫 cacheManager 之類的工具，然後手動再 put/get，也許能夠採 annotation 的做法會更簡捷一點吧 (我猜八成已經有了吧？)
ok，簡單總結，有大師的加持，今年的 JavaTwo 真的比過去幾年有看頭多了，希望明年也比照辦理的啦~~
兩場 Java Puzzles 的確非常精彩，聽完之後，對於寫 Java 程式頗有幫助。不過聽著聽著，不知不覺中，我更深刻體會到 Beyond Java 書中的感慨：一個 data type 與 object model 更 consistent 的語言，一個更 dynamic 的語言，不就可以避免掉這許許多多的陷阱了嗎？
這種感慨，以前在 C++ 出現過一次，現在又再度出現了。
由...發表 william on 八月 10, 2006 at 01:14 上午 CST #
Java 的歷史包袱很重... 有一些不 consistent 再所難免, 這真的很可惜... 不過 dynamic 能避免這些陷阱？這剛好是相反吧！
如果注意看 puzzler，會發現很多陷阱 compiler 和 IDE 直接就能幫你抓到了 (所以我之前才會說 puzzle 其實不實用)。而他們提供的建議，多半也是希望你能寫 "可以在 compile time 就能發現問題" 的寫法。這種思考方式跟 dynamic 語言完全不一樣，dynamic 根本沒有解決這類的問題，而是直接忽略，全部都是在 runtime 出現錯誤，要 developer 自己負責。也許你說 dynamic 的抓錯很快，因為多半是直譯的，可是當要整合一個 team 的成果時，這時 dynamic 語言的 puzzle 才是多咧 (誰知道是誰蓋掉誰的啊？)
我個人是蠻希望 jdk 7 or jdk 8 時，sun 能夠大刀闊斧，像 jdk5 一樣再改一次語法，最好改成像 Scala 那樣，反正 jvm bytecode 也要修，已經不能相容了，何不一起改一改呢？:-)
由...發表 ingramchen on 八月 10, 2006 at 09:15 上午 CST #
我之所以說 dynamic 語言可避免某些陷阱，是因為在這類語言中，不必用那麼迂迴低階的方式寫程式。
當然啦，dynamic type 語言比 static type 或 strong type 語言弱的地方是偵錯時間點延後到 runtime。Beyond Java 對此有一套說詞：實務上，他很少看到 Smalltalk、Lisp、Python、Ruby 等語言的使用者出現這類錯誤；而且善用 unit testing 即可補捉到比 compiler checking 更多的錯誤。
雖然這種說詞並沒有完全說服我，不過很湊巧，和你的觀點「我想唯一的解法還是多寫 unit test，這樣才能確保正確的運用 api，而且就算有 bug 找起來也快一點」非常吻合... :D
此外，可能容易混淆的是：我贊同某些更 dynamic over static type 的優點，但仍然認為 strong over weak type 的必要性。
由...發表 william on 八月 10, 2006 at 10:36 上午 CST #
我也是覺得 beyond java 的說法根本是自圓其說.... 我之前已經提過另一方的論點： "因為 dynamic 不能用電腦幫你除錯，所以你要自己擔任 compiler 的角色，寫一些本來是該電腦做的 unit test"。
如果看 dynamic 的 unit test，多半會有很多行 check type 的 assertion，這在 static type 上跟本是多餘的 (這是其中一個例子)。換句話說 dynamic 程式精簡的代價都轉嫁到 unit test 上去了。寫程式不就是希望電腦替人做越多鎖碎的事嗎？怎麼在這裡剛好顛倒了？所以我個人 "對 dynamic 的問題可以用 unit test 解決的說法" 目前也還是抱一個大問號...
Java 方面的問題 (puzzle)，其實一大半 compiler/IDE 可以捉到，要特別注意的就是那幾個而已，而且有一些是歷史的包袱，每個超過 10 年以上的語言或多或少都有一些這類的東西，dyanmic / static 都是半斤八兩。
由...發表 ingramchen on 八月 10, 2006 at 11:11 上午 CST #
"善用 unit testing 即可補捉到比 compiler checking 更多的錯誤"
我覺得 dynamic language 的愛好者, 大都是會覺得 static language 語法太過麻煩..
那, 連語法麻煩都會挑了, 會有興趣寫出比較全面性完整的 unit test 嗎?
我自己的經驗, 寫 unit test 還滿耗時間的, 常常都偷懶寫到一般狀況而已..
那, dynamic language 的愛好者會願意好好的用 unit testing 來補洞, 檢查一些本來是該 compiler 檢查的小地方嗎? 覺得不太可能呀~~
偶爾下載一些 python 或什麼的 package, 也從來沒有看過有附 unit tests..
由...發表 tempo on 八月 11, 2006 at 05:38 下午 CST #
應該這麼說：不管是用哪一種語言，靜態也好，動態也好，高階也好，低階也好，unit testing 都是必要的程序；畢竟 testing 能挑出更偏向 semanics 層次的問題。
這是管理問題，也是制度問題。
Python 文化我不熟，但 Perl 陣營可是很愛用 unit testing 的。CPAN 裡面流行的大東西通常都有附上 test suite。
由...發表 william on 八月 14, 2006 at 01:26 上午 CST #