作者 Werner Schuster 譯者 李鑫
當NET在/年第一次發布的時候Java社區認為它僅僅是從語言以及標准庫上對Java的一個克隆我們把二者的簡單實例代碼進行比較以後就可以很輕易地得出這樣一個感受不過微軟從它多年的Java經驗中獲益匪淺並且成功解決了一些Sun現在才後知後覺的問題Java社區也有人開始認為NET和CLR要比Java發展得更加快速
Neil Bartlett稱
我認為微軟在CLR上的創新速度更快是非常明顯的舉例來說LINQ就是一個極其強大的新特性（補充一下它基於Haskell語言的monads）泛型（Generics）在C#中也比在Java中得到更早更良好的支持（兩者的泛型風格都受到Haskell的多態類型類[Polymorphic Type Classes]的啟發……嗯！）CLR提供比JVM更好的多語言支持而且現在它又有了DLR而JVM上還需要兩年時間才能出現能夠相提並論的產品
其它的例子有
模塊化以及版本控制對此NET采用了Assembly（一些類的集合）離作為基本的部署單元來解決這個問題Assembly包含了諸如版本信息之類的元數據與之相反的是Java的Jar文件是缺乏這些版本信息的元數據的這個缺陷會為那些加載了許多類庫不斷增大的大型項目帶來許多麻煩目前OSGi為這個問題提供了解決方案而Sun也正在為將類似的解決方案加入Java 中而忙碌著
通過增加泛型自動裝箱（AutoBoxing）枚舉類型（Enumerated types）和Annotations等特性Java語言正在不停地追趕NETC#現在提供了對匿名表達式的支持這個特性是LINQ技術的基礎組成之一LINQ可以被認為是一種針對多種不同數據源的靜態類型查詢語言這裡說的數據源可以是XML可以是關系數據庫甚至可以是任意的對象圖與此同時Java社區還在爭論語言的瑣碎問題比如說語言支持的屬性（Properties）以及到底四種匿名方法（閉包）的哪一種應該被語言內建支持
隨著DLR的發布微軟再次領先了這一次是在CLR對動態語言或者腳本語言的支持領域再次開始領跑Java領域目前還沒有能夠相對應的措施Mono項目是一個非常純淨的NET實現它的發起者Miguel de Icaza對DLR的特點概括如下
·一個針對動態語言的共享式類型系統
·一個共享的AST可以被語言開發人員用來創建新的動態語言
·針對編譯器開發人員的輔助/工具類
·一個通用的宿主接口從而可以將通用腳本語言的接口嵌入你的程序中並且允許開發人員用一種貨多種動態語言擴展系統
·控制台支持DLR甚至提供了一個簡單的控制台接口用於進行交互式編程
共享式類型系統（Shared Type System）是使動態語言之間能夠互動及交換對象重要因素Jim Hugunin揭示了隱藏在這之後的機制並且演示了Java是如何處理這種情況以及DLR是如何獨辟蹊徑的Jim Hugunin肯定明白之間的區別的畢竟他開發了Jython項目一個基於JVM的Python實現最近他轉向微軟平台並且開發了IronPython（基於CLR的Python實現）
Jim Hugunin是這樣解釋其中一個問題的
使用Wrapper（包裝器）的方式也可能會有更深層次的問題挑戰之一就是確定需要傳遞的對象舉例來說如果Python有一個PyString對象並且它調用了一個需要Object的C#方法是應該傳遞PyString對象呢還是應該將它解包成一個String對象呢？這些非常難以捉摸的類型問題永遠都沒有一個完美的答案更糟糕的是想在程序員不知情的情況下對對象進行包裝或者解包而導致對象標識的丟失而引起的一些超級棘手的問題
這些問題毫無疑問也存在於Java領域中比如說JRuby 在Java和Ruby代碼間處理字符串傳遞的方式
·傳入Ruby代碼的Java字符串將被編碼為UTF這暗示了你應該在接收參數的代碼中用UTF byte[]來工作
·Ruby 字符串傳出到Java時也被假定為UTFJava端調用的返回結果應該符合該假定
Java領域並沒有實現我們上面提到的那些東西除了宿主接口（Hosting Interface）它將在Java 中按照JSR 的規范實現（Java中的）宿主接口只是一個框架該框架提供添加新的語言運行時並對其進行初始化和訪問的標准方式
Jim Hugunin進一步揭示了動態方法分派是如何被處理的這個過程利用了擴展方法（Extension Methods）以及其它已有的CLR系統在Java方面唯一可以相提並論的努力就是JSR 其中要做到的一件事就是為了加入一種新的字節碼invokedynamic這個想法來源於Gilad Bracha他在創建了這個JSR之後很快離開了Sun公司現在他並不看好這個項目會在短期內有任何解決方案出台
JSR 是我為了解決這些問題所發起的一項努力我希望在缺席的情況下它仍能繼續下去但這個項目還需要若干年才能出成果（如果可能的話）坦白地說向JVM為這些特性添加支持然後使Strongtalk變得更穩定是更為困難的一件事情
注Strongtalk是一個Smalltalk實現其VM是HotSpot技術的基礎而HotSpot技術已經隨著Sun的JVM發布很長一段時間了
JSR 的規范負責人Danny Coward則對在性能上帶來的改善更有信心
動態語言引擎的創造者們正在忙於將Ruby代碼轉換成Java的字節碼當JRuby的引擎嘗試著將方法調用轉化成字節碼時就必須創建一個合成的接口來表現返回類型這並不是開發人員創建出來的接口而是由JRuby引擎所創建的所以引擎可以處理這個方法調用並且將其轉化成字節碼而那就是返回的類型——對於方法參數和異常也是同樣一個道理
JSR 消除了對這種合成接口的需要在今天動態語言解釋器必須輸出方法調用的字節碼即使是在解釋執行比如說一段Ruby代碼的時候明天有了JSR 解釋器將會用到invokedynamic版本這將使動態語言引擎實現變得更加簡單因為現在的許多引擎對創建新的合成接口以及做許多簿記工作煩惱不已當一個方法在七八個不同的地方被調用時引擎就必須在所有（調用的）地方重用那些合成接口
值得關注的是這些改進都將被寫入JVM規范中這就意味著這些特性都將被內建支持（被硬編碼進去）並且在將來就不容易升級了基於類庫的方法好處在於當處理這些系統更好的方法出現時這個方法可以很快被采用基於JVM的方法將在很長一段時間內保持不變因為JVM常常會有一個很長的使用周期（作為參考Java 現在還在被許多公司所采用）JVM真的會采用這種字節碼並且改進動態方法調用的速度嗎？這也還有待觀察
另一個問題是官方對基於JVM的語言的支持和認可目前JRuby有兩名開發人員在領著Sun的薪水其中一位是Charles O Nutter他已經加入了Jython和Groovy的社區當中這些努力是否會開始還有待於觀察考慮到微軟有致力於IronPythonIronRubyJavaScript以及動態VB支持等各種動態語言的緊密合作的開發團隊微軟在這方面具有一定的優勢畢竟DLR是一個不同團隊合作的產品這些團隊在分享他們的經驗並將這些經驗融入一個通用的類庫和知識庫中與之相反的是基於JVM的開發團隊經常不得不重復吸取重要的教訓
舉例而言JRuby的特色之一就是它的即時（Just In TimeJIT）編譯器這個編譯器將在運行期將Ruby代碼轉化為Java字節碼問題在於在當前版本中這樣的代碼會使基於set_trace_func的調試器（這些調試器使用回調的方法來實現調試器功能）不能正常工作因為代碼不再調用這個回調這意味著JRuby的調試要受到這種方式的影響而同樣的問題肯定要在每種語言中得到處理和解決因此共享哪怕是這樣的一小部分經驗或者代碼都會幫助其他人節省時間和工作
補充觀點微軟的DLR還有待證明自己目前集成了IronPython的DLR已經可以在網上下載到IronRuby還沒有發布並且它的真實速度以及通用互操作能力還有待檢驗比起NETJava仍然還有被認為是更加開放並且能運行在更多平台上的優勢不過Miguel de Icaza看起來確信Mono在今年結束之前將能提供對Silverlight的支持
From:http://tw.wingwit.com/Article/program/Java/JSP/201311/19372.html
