Java 與 .NET 的平臺發展之爭

jopen 11年前發布 | 17K 次閱讀 Java

        英文原文:Java faces tough climb to catch up to .Net

        Java 8 即將正式發布,從早期版本中,我們已經可以領略到一些令人興奮的特性。但是開發者 Andrew C. Oliver 表示,盡管如此,Java 語言在某些特性上還是落后于 .Net。比如,Java 8 中最令人期待的 Lambda 表達式,在 2007 年發布的 .Net 3.5 中已經存在了。他認為,.Net 已有的和即將到來的特性要比 Java 8 優秀得多,如果 Java 9 再不做一些大的改進,那么 Java 落后于 .Net 就不止一點點了。

        關于更新速率

        微軟有能力做出更快的改進。我記得在很早期的時候,微軟能做到每周都更新數據庫 API:從 ODBC、RDO、ADO 到 OLEDB 等。自從出現了 .Net 之后,微軟便達到了一種前所未有的更新速度。

        但是 Java 為什么落后這么遠?在早期的時候,Java 的發展也是非常快速的,從 Java 1.0.2 到 Java 1.1,僅僅一年時間,我們就看到了 Java 徹底地改變。從 Java 1.1 到 Java 1.2 只用了一年半時間,而 Java 1.2.2 只用了 7 個月的時間(這是一個重要的版本,只是使用了一個小版本號)。而在 10 個月之后,具有關鍵意義的 Java 1.3 問世,這也正是 Java 發行的第一個帶有垃圾回收的版本。

        Java 1.4 為我們帶來了 NIO 和正則表達式,但在之后不到兩年的時間里就被取消了。Java 1.4.2 版本帶來了用于多核環境的垃圾回收器。Java 1.5 帶來了可用于生產環境的并行和并發 GC(垃圾回收)特性,它還添加了更重要的并發和 NIO 功能,不過這一過程花了一年多的時間。

        總的來說,Java 還是有不錯的表現的,Java 6 使鎖變得更廉價,但其在本質上和 Java 1.5 是一樣的,還是讓用戶多等了 2 年時間。Java 7 是第一個對底層 VM 技術做出重大改變的版本,同時還給用戶帶來了 invokedynamic 特性——用于在 JVM 上更好地連接其它語言,但是在兩個大版本的更新之間用了大概 5 年時間,這個進度著實有些太慢了。

Java 與 .NET 的平臺發展之爭

        為什么 Java 進展緩慢?

        對于這個問題有一個簡單的解釋:Sun 并不是一個實力超群的公司。Java 創造于互聯網繁榮時期,而那個時候 Sun 正在出售 Sparc 業務。

        之后,互聯網經濟不景氣,Sun 決定持續加大其在硬件業務中的投入。Sun 比較擅長創建生態系統,但它就是無法創造出用戶需要的產品。Oracle 是 Sun 的后繼者,擅于徹底毀壞生態系統,最終吞并/摧毀圈內的同行,還會開發出高利潤的產品來取代同行。

        Oracle 曾在一份簡潔的公開聲明中稱:“我們都知道,由于各種商業和政治原因,該版本(Java 7)花費了不少時間。”

        當然,在分析 Java 的問題上,我們還必須考慮 Sun 公司的財政困難以及 Java 系統周邊的東西。Sun 公司違背了其提交 Java 進行標準化的初衷,它創造了自己的“標準”委員會,即 JCP(Java 社區進程)。隨著時間的推移,JCP 盡管在一定程度上已經開放,但是無論是 Sun 還是現在的 Oracle,都擁有絕對的否決權,它們可以忽略規則,做任何想要的事情。

        什么阻礙了 JCP?不是開放性,而是利益沖突。我記得當時參與 EJB3 規范制定的某個供應商,它習慣延遲規范的進度。這是為什么呢?這些供應商需要購買或開發一個產品來集成到它們的應用服務器中,如果下一代 JavaEE 規范已經發布,那么它們也必須盡快推出產品,它們不希望比市場晚。

        協調產品的發布,對于一個公司來說都有些難,更不用說幾個公司了。因此,我認為 Java 最大的問題并不是由于 JCP 造成的。

        拋棄或分離一些東西

        Sun 已經成為了過去時,現在 Oracle 是“老板”,那么為什么 Java 版本的發布周期仍然需要這么長?最簡單的解釋是——Java 太大。大項目往往意味著進展比較緩慢,且充滿風險。下面我們就來看看如何將 Java 變得小一些。

        首先,Oracle 必須擺脫其“心愛”的客戶端技術。當然,目前還沒有更好的 Swing 和 JavaFX 的替代品,但是使用這些技術意味著需要把你捆綁在 Oracle 的平臺上——至少目前是這樣。

        我尚不清楚,目前 JavaFX 或客戶端 Java 為 Oracle 帶來的戰略上的意義是什么,它們似乎被設計用來和 VB6、Flash 或一些 4GL(第四代語言)進行競爭的。在現代的、多平臺的環境中,大部分人會認為觸摸和滑動操作會更酷一些,而 JavaFX 與這種趨勢是不相匹配的。為什么我們需要使用客戶端 Java 來阻礙服務器端的發展,并且還有可能伴隨著各種風險,比如持續數月的 Java 零日漏洞安全問題以及關于如何禁用 Java 的討論。

        如今 Java 語言已經不再和 Java 平臺一樣重要。從 Java 平臺中砍掉 Java 語言,并根據自己的時間表進行發布,這對于 Oracle 來說可能更容易——Oracle 推出的開發工具不是 Java 業務的重要組成部分,并沒有為大部分的 Java 開發者所使用。

        Java 平臺上有多種語言,比如 JRuby、Scala 等等。以高性能和可擴展的方式來支持這些語言和技術,對于云計算來說非常重要。如果云計算是未來,那么 Oracle 應該首先考慮 Java 平臺。而目前所支持 Ruby、Scala、甚至 Node.js 的 Java 平臺似乎是一個“錨”,而不是產生創新的“引擎”。

        比起 Mark Reinhold(Java SE 規范領導者,目前在 Oracle 公司),我更希望由 Charles Nutter(JRuby 創始人,目前在 Red Hat 公司)和 Martin Odersky(Scala 創始人,目前在 Typesafe 公司)來決定在 Java 平臺中添加哪些特性。我并沒有不尊重 Mark Reinhold 的意思,但是一些證據表明,在很多與 Java 語言合作的項目中,Java 語言拖慢了項目的進度。

        對于 Oracle 領導的 Java 來說,事情發展不會那么順利,很多 Sun 之前的決議現在仍然在困擾著我們。我的建議是,拋棄客戶端 Java,獨立出 JVM 和 Java 語言的發布周期,致力于將 Java 作為一個平臺,而不是想一次性地解決所有問題。

來自: www.iteye.com
 本文由用戶 jopen 自行上傳分享,僅供網友學習交流。所有權歸原作者,若您的權利被侵害,請聯系管理員。
 轉載本站原創文章,請注明出處,并保留原始鏈接、圖片水印。
 本站是一個以用戶分享為主的開源技術平臺,歡迎各類分享!