寄件者：cosmoschen (cosmoschen@bbs.openfind.com.tw)
主旨：Java之我見
这是仅有的一条留言
View: Original Format
日期：2002-11-01 02:20:14 PST
Java跟.NET，C++的爭吵也不是一天兩天的事了，尤其在Java版上，三不五時就會有人來小吵個一下，然後大家群起圍攻，或是M$出個什麼新技術評比，然後接著有更多人加入戰局……
我想回到最初學OO的開頭來試著說說我對Java的看法：OO之於傳統語言的好處是什麼：元件再用性跟接近真實世界的思考方向。這個聖杯造成不少人的投入，然而，進入OO其實正意味著思考邏輯的重整，從分析、設計到實作都有許多新議題要解決學習，那為什麼我們還要OO？相信這個答案大家都很清楚：一、減少解決問題的時間，二、簡化未來的維護時程、三、將精良的程式碼再用。
實現的技術很多，Java不是第一個，相信也不會是最後一個希冀解決部分過去C++ OO問題的答案，我個人偏好Java的原因是：Sun注重良好的架構跟規格，並且在產品實作上提供許多不同的選擇，不會被特定的廠商或技術綁死，同時Java把程式設計的工作簡化了！
俗話說「有一好嘸兩好」，良好的架構規格可以幫助我們簡化維護時程，但要學架構規格卻也要花時間；簡化程式設計師的工作通常意味著背後的運行平台要提供更多的系統服務，因而減低了執行效率；只定規格不鎖死產品代表選擇多，但同時對技術的學習者來說反而因為五花八門而有不得其門而入的困擾。
但這還只是前期的投資，等我們學會了「基礎」的Java語言API語法之後，背後的龐大架構、設計規格才剛開始，我們還有粉多路要走：J2EE是一個例子，提供將商業邏輯元件獨立開來，並達成高再用性的應用。我想有很多人只看寫個EJB要分成HOME/REMOTE/BEAN/DD就頭痛了，更不要提EJB還有Session/Entity/Message Driven的不同應用，再加上Weblogic/WebSphere……這些廠商雖然技術相容，但實作上還有些微差異要克服，於是，很多人會想大喊：「給我一條捷徑！」
這也是我剛學Java時一直不斷抱怨的問題：二年前Java的中文書不多，剛好Java 2又推出，新舊技術交叉，光看原文書都不知道該相信哪個版本好，而MS總有官方版本的最後定奪，同時光一個免費的MSDN就夠你看到天荒地老，更不用提MS高檔的行銷手法跟華麗的產品包裝，一個.NET被稱之為「跨語言、平台、服務的最終應許之地」，讓我當時真有想轉往MS陣營的衝動，真正阻止我過渡的原因是：.NET的產品時程跟封閉性，造成跟了上述一、二、三點的衝突。
個人沒有批評任何平台的意思，目前也正在學.NET相關技術，但我不斷回想這些問題並蒙心自問：真要等到別人解決問題我才能搞定自己的問題嗎－－當然是讓我養家糊口的過程輕鬆些－－.NET推出的實作版本持續修訂，不斷跟著所謂「口號」改變方向，從ASP.NET/C#/J#到Framewrok的改版，這些說好聽是進步，說實話是折磨，要用技術當然是希望產品已經到某一個成熟的階段才開始學習，但市場、老闆是不等人的，所以我接受了這些試煉。
回過頭來看看Java，從1999年J2EE推出到現在有三年的時間，Java並不特別宣稱解決哪些問題，但我從個人的角度來看Java平台解決了哪些問題：一、架構性輔助了開發上多人多工的獨立性；二、語言的簡潔省確了開發除錯的爛攤子；三、元件設計的強調符合了再用與維護的難題，這也是為什麼個人還是十分喜好Java的因素，縱使未來加入了新的技術－－像是最近的Web Service－－Java良好的架構讓她在設計解決方案時有個良好的切入點，而且不會牽一髮而動全身，大家再看Servlet/JSP這些J2EE的技術來當成例子，有了Java API的規格跟輔助，要進入這些領域其實不難；有了良好OO觀念，再去看這些元件的設計理念也相對輕鬆不少，你願意拿前期的投資換後期的豐收嗎？
接著看看Java一直不斷被垢病的效能問題，在這裡個人的意見是：為了快速開發、簡化維護、再用元件，慢一點又有何妨？更何況在*NIX上Java的效能表現硬是比MS平台上快了許多，如果還覺得慢，換個作業平台或佈署到平行處理的伺服器陣列如何？這些工作可是在.NET上未曾被討論的－－有興趣的可以試試架MS Cluster Server－－我不提最佳化處理這些方案，因為這是上述兩者都可以採行的。
再來談談OO的其他部分OOA/OOD/Design Pattern與Refactoring，不管你熟悉與否，這些技術都是讓開發工作「更快更輕鬆的」解決方案，不過這些領域也具有超高的進入門檻與學習曲線，同樣一句老話：你願意拿前期的投資換後期的豐收嗎？用Java實作這些技術並不難，同時Java本身也應用了許多這些技術，並且實作了許多年。當然.NET也有，但我看不到MS的誠意：因為現階段的規格高變動性讓她不願意在此時提出這些議題，這也代表了要切入中大型市場的未來潛在陷阱：一個倉促實作迎合某些口號的技術規格後面會有多少要我們來承擔的後果，這留給大家去思考。
台灣的市場偏向於中小型的開發，因為台灣企業本身也是中小型為主，有很多過去的討論著原在快速的開發與簡易的應用上，這無可厚非，關於這點我的說法很簡單：「殺雞何必用牛刀？」要速成短小請用Perl/PHP；要高速運作請用C；要極致追求效能請換Assembly，後果是：如果你有了下一版－－如果存在的話－－那你花費在改版的時間可能等同於重寫的時間，最後一次提那句老話：你願意拿前期的投資換後期的豐收嗎？如果覺得是：請花點時間看架構、體系、設計、分析、重用的議題，而Java可能是目前應用上最容易入門且學了拿了賺錢的好選擇之一。
--
