Java能夠成為完美的技術平臺嗎？(轉)

Java能夠成為完美的技術平臺嗎？(轉)[@more@]　　譯者語：在網上有關Java與其他語言或平臺孰優孰劣的討論一直沒有停止過，甚至現在還是有人會提出這樣的問題，特別是一些初學者，對此更是迷茫。這篇文章比較客觀全面的評價了Java的各個方面，它既談了Java的優點也討論了Java的一些缺陷和有待改進的地方。我認為很值得大家參考所以翻譯了出來，希望對關心Java的人有所幫助。

　　前言

　　象許多在不斷髮展的平臺/語言一樣,Java讓很多程式設計師又愛又恨。當然，這不包括那些狂熱的Java愛好者，對於他們來說Java比.Net,LAMP或任何其他語言或平臺都要好。但是，我們還是不得不面對複雜的Swing，龐大的EJB規範等對硬體的額外要求，以及J2ME的變化多端的實現方式等等等等。拋開以上這些Java的弱點，我們可以說Java是一個完美的技術平臺，那麼Java到底有沒有成為一個完美的技術平臺的潛力呢？

　　這篇文章將從兩個方面討論這一主題，開始，我會詳細的告訴你什麼是完美的技術平臺以及為什麼Java平臺能夠成為完美的技術平臺。之後我會偏重於具體的解決方案，如何透過設計的最佳化避免Java平臺的弱點。

　　基礎

　　首先，你為什麼會關心Java是否是一個完美的平臺？它現在不是也很好嗎？不，不是的。我相信在文章結束的時候，我將向你展示一些列Java中可修正的缺點。解決這些缺點會加快Java平臺的發展，提高整個開發平臺的效能。簡而言之，它將使Java不管在工業還是商業領域都成為一個實際上的技術標準---成為程式設計師的一個超級語言。

　　什麼才是完美的技術平臺？

　　在我作進一步說明之前，我應該先定義一下我認為的完美的技術標準是什麼。簡單的講，我認為完美的技術平臺應該是這樣一個軟體系統，它可以讓新手或高階開發人員都能使用，能夠編寫簡單的程式也可以編寫高階的應用，它應該能夠執行在所有的硬體平臺或作業系統平臺上，並且應該是本地化的操作或接近本地化的操作。

　　定義這篇文章討論的範圍

　　類似這篇文章的主題，事先定義一個範圍是很重要的。首先，我們不討論任何非Java的技術平臺。你也許會認為這有些太狹隘了。我不這麼想，這篇文章是要單獨的討論Java平臺的各個方面，並不是要和其他的語言平臺進行比較。我的興趣在於那些為了完善Java平臺提出的具有建設性意義的觀點。如果可能，我希望其他技術平臺的支持者能夠發表類似的文章提出他們認為最完美的技術平臺。

　　另外，我在這裡還假設Java語言已經是各種技術平臺中最佳程式語言。並且我也不會討論最新的Java2平臺J2SE1.5,儘管在J2SE1.5中我可以感覺到其中的一些變化比如標有” keeping up with the Joneses”的是把矛頭指向了C#語言。一個語言的穩定與否至少需要將近8年的不斷驗證才能證明它的最初設計是否是健壯的。引數化集合的實用性在JDK1.5中是顯而易見的，其中的一些新特性比如autoboxing, enumerations和 static imports引起了開發人員的廣泛關注。

　　Java繼承了來自C和C＋＋的健壯行，它一開始就被設計為一個物件導向的語言，我認為這是一個成為核心語言和優秀平臺的關鍵所在。當然這並不算什麼先進的思想因為從最早的Eiffel到Smalltalk都是物件導向的語言，那麼Java和他們之間有什麼根本的不同嗎？Java和那些比如功能性程式語言象LISP、Haskell或象SQL這樣的可以透過語義來執行的語言又有什麼不同嗎？畢竟我們學習這些語言只需要一本手冊就可以了，但別高興的太早，如果一個市場上主要的廠商比如SUN,HP或微軟想要把這些語言中的一種拿出來，並圍繞它開發他們的下一代技術平臺，你會發現這個語言將不會再進一步更新；

　　我喜歡把Java作為一個平臺來看待；實際上Java作為一種語言來說在Java平臺中只是較少的一部分。也因此我會在下面介紹作為一個完美技術平臺的重要特徵。

　　什麼才是完美的平臺

　　比較起來，對於這個主題來說可以講的很詳細也可以講的很簡短概括，我選擇了後者。對此有興趣的讀者可能會注意到，在有關這個主題的詳細討論中很多詞彙後面都會有一個”ility”作為結尾，你知道它是ility矩陣（matrix）的意思。在我看來作為一個完美的技術平臺應該具備這些條件：

　　便於開發，而且提供多路訪問(詳見下面的討論)

　　穩定性，這體現它應該便於客戶平臺的部署；還應該是本地化模式的部署操作。

　　必須具備可靠的效能和可測試性。
　　
　　基於開放的標準。

　　Java符合這些標準嗎？

　　到現在我已經定義了一系列符合完美技術平臺的標準和特徵，讓我們看看Java的成長過程是否符合上述的特徵。

　　我不得不痛苦的承認，開發Java程式並不容易。相對簡單的專案還好，但如果專案不斷增長以至於變得越來越複雜就會不斷出現越來越多的問題。比如J2EE應用就是這樣。因此在專案的開發中程式設計師需要花更多的時間來跟蹤底層的問題----比如類引導(classloading)問題而不是解決實際的業務邏輯問題；還有令很多程式設計師頭疼的EJB(檢視我過去的文章To EJB, Or Not To EJB?),通常情況下他們都是在清除一系列的警告資訊。EJB也許想把複雜的問題簡單化，但是它並沒有更貼近於現實中的持久化問題或業務邏輯的解決方案，這也與Java開發工具的不足有關。坦率的說，微軟的Visual Studio在這方面比Java作的要好，Java應該向它學習。

　　我曾經提出過一個多層次訪問的想法，它允許開發人員或者使用者可以工作在Java中的不同層次。比如核心開發人員可能使用emacs/vi以命令列偵錯程式的方式開發和部署以Java為基礎的系統，而業務分析師或終端使用者應該能透過使用WYSIWYG這樣的工具來訪問和修改這個系統。

　　Java在這兩方面的開發並不是很容易。當然applet和JavaWeb Start技術在這方面作出了一定改善，但這兩種技術也有自己的不足---執行他們必須在客戶端安裝配置JRE。Java平臺是想當穩定的，我已經不記得上一次因為Java本身的bug而給我帶來麻煩是在什麼時候了。所以如果要作一個企業級應用的話我寧願選擇J2EE而不是.Net。

　　Java在伺服器端的應用是足夠穩定和健壯的。Swing客戶端的應用表現也不錯，但在執行速度方面比起本地的應用要差一些。由於資源限制的原因比如行動電話(或智慧終端)，如果使用Java而不是用本地化的開發工具，從實用性角度來說就顯得有些奢侈了。附加額外的MIDP載入比起直接呼叫本地的應用造成了執行時的效能損失。

　　很明顯，Java有來自業界的主要軟體廠商的廣泛支援（除了微軟）。比如IBM，HP，Oracle已經把他們自己的技術整合到了Java平臺上，這對關心Java的人來說是個好訊息。還有更多的組織和團體花大量的精力不斷的完善Java，他們希望看到Java在移動裝置，PC，伺服器等各個領域不斷的成長、進步。

　　優點

　　Java的優勢在哪裡？

　　平臺支援：J2SDK已經可以執行在任何的作業系統和硬體平臺上，從金融機構到娛樂設施，從科學研究到家用電腦都可以使用Java。

　　Java語言規範和Java執行時規範的明確分離允許研究人員可以透過執行一個編譯器來產生程式語言的對映，而不必非要使用Java來編譯二進位制碼――也就是說它可以執行在任何的虛擬機器(VM)上。這一點在我後面要提到的Java戰略的改變非常重要。

　　Java是當今企業級計算和應用中相當成熟和穩定的平臺。微軟仍然在不斷的改進他們的.Net，而且可能最後會象Java一樣好或者比Java好要好(但這隻侷限在Windows平臺上)，但現在還作不到；另外，還有另一個競爭激烈的領域，那就是移動裝置。儘管在前面我們提到過Java在節省裝置資源方面相對較差，但是不可否認在這個領域它也佔據著領導地位。

　　Java在學術界也獲得了強有力的支援。如果你在大學學習你會發現Java已經成為多數科學研究和計算使用的首選語言。在大學中有越來越多的人在使用Java語言，越來越多的尖端學術研究完全使用Java語言；各個行業的公司都有很多的Java程式設計師在開發他們的專案。

　　缺點

　　現在我們來看看Java的缺點：

　　一個開發組織建立新的框架和元件庫幾乎總是在存在優點的同時也存在著不足。一個優秀的元件技術總是在不同的開發人員和組織間相互競爭和促進中成長起來的。但是在這一過程中，卻使得使用者(這裡特指開發人員)非常困惑。儘管Sun一直在忙於應付，但是就到底是使用JDO還是EJB更好一直存在著爭論。的確，我們必須確定把哪一個繼續發展下去。現在我們能作的就是把這一個想法簡單的提交到JCP組織。比如，如果你是一個J2EE設計師，你能100%確定當前哪一種才是完美的解決方案嗎？我不能，但我的觀點是“注重實際的方案就是完美的方案”。

　　現在有一種觀點認為Java過於複雜。有誰能完全瞭解Java從伺服器到PDA各個方面的所有知識嗎？作為一個博大精深的語言，Java在人們生活的不同領域都無處不在，這不可避免的帶來了它的複雜性，但同時這也更值得開發人員在其平臺上使用Java來開發不同的應用。Sun的一句明言就是“嘿，我們已經給了你一個非常棒的核心技術。現在你可以用它來建立任何開發工具或健壯的產品”。其中非常活躍的Jini/JavaSpaces就是一個例子。Sun自己把這一技術作為一個學術研究的工具，它幾乎沒有什麼技術缺陷。實際上，基於JavaSpaces的程式設計模型也許是最簡單最強大的技術之一。

　　Windows 家族整合了很多繁瑣的分散式客戶端平臺。除非與Java捆綁否則Windows技術永遠無法避免這些缺點。當然，隨著.Net的崛起，Java 在客戶端程式設計(thick-client)方面將失去了很多優勢。

　　我不認為Sun為Java投入了足夠的財力。這給Java帶來了潛在的隱患，那麼為什麼Sun應該繼續對Java平臺投資呢？我更樂意看到Sun透過大量的財力扮演一個“善意的獨裁者”，它將透過與象BEA，IBM,HP等這樣的公司而不是和開發人員或終端使用者一起合作來指導Java的未來。我擔心來自Sun對Java的動搖。Sun公司的健壯穩定的發展預示著Java的不斷完善；如果Sun出了問題那麼Java的發展和完善也將受到影響。下面的圖示顯示了影響Java技術平臺的幾個方面。

　　圖1顯示了高層的理想化的Java技術平臺。其中，由Sun及其合作伙伴控制的技術顯示為橙色，其他不屬於Sun的為綠色。


　　Java有哪些缺點

　　無疑，我承認Java平臺是有缺陷的，這必須指出。下面幾節將詳細講述這些問題和戰略及戰術上的建議。

　　有關J2SE

　　對於大多數開發人員來說，誰使用Ant作為他們的編譯工具；誰出於執行效率的原因使用了Jikes編譯器而不是javac編譯器。如果J2SE包含Ant不是更好嗎？Xdoclet怎麼樣？爭論的焦點在於，這些工具應該是IDE的一部分而不是核心SDK的一部分，我很高興這樣。但是我以為Sun應該把這些工具集合到一起使他們可以安裝在現有的SDK上。

　　最優產品

　　這是一個痛苦的抉擇。當我提到把當前的javac換成Jikes時我總是覺得很不好受，但是這裡我把它當作Java平臺的一個通用規則來看待。Java平臺需要成為一種技術權威，比如，它應該成為一個實際上的技術標準。當存在兩個健壯的規範或工具的話他們應該相互合併。比如一個較為突出的例子，NetBeans-Eclipse之間相互競爭，我們就應該只留下一個最好的。

　　我使用Eclipse，但是為什麼我們要在一個專案中使用兩種Java IDE，而且還不得不使它們相互諧調工作，而不能有一個集合了每個工具的優點的合併的工具呢？Eclipse 的SWT在執行效率上要優於Swing/AWT，而NetBeans對JSP有很好的支援，它可以使開發人員的工作變得輕鬆。

　　Sun：發出一致的技術訊息！

　　想想持久化架構：EJB（BMP和CMP），JDO以及Hibernate。還有WEB架構領域的Struts和WebWork。這些對於一個企業來說都是很好的選擇。但在他們之間作出取捨卻讓人頭疼。作為一個系統設計師，我有理由作出選擇。比如，什麼才是理想的J2EE架構？簡單的回答師“它取決於需求”，但這是在逃避問題。一個三層結構的企業級應用中了包括顯示層，業務邏輯，以及持久化層。對於上面提到的技術我們應該可能會選擇其中之一或者有可能是兩種。

　　作為企業同樣會遇到選擇應用伺服器的問題。我很欣喜的看到現在有很多廠商的應用伺服器都支援J2EE1.3規範，但是我認為首選的應用伺服器應該具備下面的條件：它應該能夠減少開發的難度和工作量並且能夠滿足複雜的測試還要提供更簡單的小組控制支援。假設我在使用過程中碰到產品的Bug或者乾脆這個應用伺服器的廠商倒閉了，那麼根據J2EE規範應該能夠允許我很容易的移植到新的伺服器平臺上。

　　新規範和應用實現的制定者有義務建立一個應用程式設計藍圖，它要示意這個應用進一步的發展方向是什麼。

　　有關Java的一個新的觀點：讓一切變得簡單

　　2002年JavaOne大會上James Gosling在談到Swing API 時說道，不管是對於一個新手還是一個有經驗的程式設計師來說Swing API就像波音747客機的駕駛員坐艙-――結構複雜。

　　談到這，我認為解決這類問題的根本在於Sun、JSR和那些開源專案的主管們，他們應該減少軟體的複雜性。不論是規範API，軟體安裝的模式或配備的文件等等都應該符合這一原則。

　　Java World需要採納KISS的觀點，即保持簡單化，傻瓜化(Keep It Simple,Silly)。

　　選擇Windows作為客戶端開發的平臺
　
　　這一觀點有可能會帶來爭論！直說吧，Java在Windows平臺上並沒有產生多大影響，不是嗎？實際上，我認為在Windows平臺上Eclipse專案的SWT是強制使用了本地化的外觀樣式和執行環境，並且與Windows的剪貼簿及OLE機制緊密的結合。

　　不要誤會我的意思。我並不是說Java應該支援Windows平臺而忽略其他的平臺比如Mac或Linux，我是說對於Windows平臺的支援應該得到重視和加強。比如象在這方面已經有所進步，但仍然有很多事要做。

　　把Java平臺當作其他技術的基礎

　　我非常讚賞Java把它的語義部分與執行時環境(JVM)規範分離的做法。這一點可以使Java能適應任何開發。理想情況下我希望其他技術可以以Java為基礎並能與之無縫的結合（譯者語：比如Jpython就是一個例子）。

　　JCP "lite"

　　JCP(Java Community Process)是一個機構，它使Sun可以扮演一個 “善意的獨裁者”的角色，由它來引導Java平臺的不斷髮展，其他個體（包括公司或個人）可以在Java平臺上增加新的功能。

　　然而現在，有關J2ME，J2SE和J2EE規範的制定在JCP中出現了巨大的阻礙，而之所以會出現這些阻礙是由於各個廠商出於商業的考慮或政治的目的等原因造成的。

　　每一個JSR規範一般有兩個版本：一個是我們現在看到的版本另一個是大約50多頁專為開發人員準備的，它們必須使用和理解並最終實現這一規範。

　　圖2列出了當前Java存在的不足及相應的解決方案。


??結論

　　那麼，現在的Java怎麼樣？套用一句俗話“只要努力，就會更好”。Java有潛力成為從PDA到伺服器任何領域都非常成功的平臺。Java可以繼續在其佔優勢的伺服器端發展下去。還可以透過最佳化客戶端程式的釋出及安裝使Java在客戶端開發方面一樣獲得成功。

　　不管現在的情況如何，我相信Java有能力成為一個完美的平臺。透過不斷的完善，降低開發人員入門的難度，提供對所有的平臺和作業系統的支援，以及提供對更多語言的支援，Java平臺將可以適應任何層次任何領域的開發。透過對客戶端平臺的最佳化Java在PC和移動裝置領域中也會獲得巨大的成功。