JVM的動態語言支持：為新一代流行語言鋪平道路
Java SE 6已不再局限于Java語言了，因為SE 6還可以用來執行動態腳本語言代碼。據Sun公司Java SE平臺項目的負責人丹尼·考沃德（Danny Coward）稱，Java虛擬機要成為所有動態語言的最佳執行平臺，而提供腳本語言支持只是實現這一計劃的第一步。2006年12月11 日，Artima記者弗蘭克·索莫斯（Frank Sommers）就JSR 292——支持Java 平臺上的動態語言特約采訪了考沃德。
Java SE 6可以加入對Java平臺腳本JSR 223的實現，從而可以被用來執行以Ruby、Python、Groovy或者JavaScript等動態語言編寫的腳本語言代碼。但是，丹尼·考沃德認為， Java虛擬機是專門為靜態語言而設計的，要在這樣一個平臺上實現動態語言解釋器絕非易事。考沃德是Sun公司Java SE平臺項目的負責人、JSR 292規范的主要制訂者。
在Sun即將發布Java SE 6之前，Artima記者和考沃德進行了一次訪談，其中談到了Java虛擬機動態語言支持的未來、invokedynamic——一個專用來設計對動態語言對象的支持的新JVM 指令、運行時改變或添加類方法的hot-swapping，以及將Java虛擬機變為動態語言實現理想平臺的目標。
弗蘭克·索莫斯 : Java SE 6最大的特征之一就是對動態語言的支持。您能向我們描述一下在現有的Java SE版本中，這一目標將得到怎樣的實現？今后還會增加哪些對動態語言的支持？
丹尼·考沃德: 在過去的幾年里，我們已經注意到了一種現象。和.NET開發者社區不同，Java開發者社區早已經開始體驗動態語言了。動態語言逐漸成為許多開發者 Java應用開發日常工作的一部分，并常常用于原型開發（prototyping）或用來提高開發速度。為了快速得到更大規模的（Java）應用程序，人們一直在使用動態語言膠合程序部件。
今天，Java平臺的腳本JSR 223將與Java SE 6一起發布。在聚集動態語言愛好者這一方面，JSR 223邁出了它的第一步。首先，它為開發者提供了允許將其它語言的代碼與Java代碼混合起來的API。其次，JSR 223還是一個框架，它允許開發者插入用來解釋動態語言的腳本引擎。在Java SE 6中，我們增加了Rhino JavaScript引擎，這樣非傳統的開發人員也可以使用JavaScript。
開發者也可以使用腳本引擎的框架來插入自己的解釋器引擎。我們已經從scripting.dev.java.net 上的java.net腳本項目中收集了二十多種動態語言引擎。這是Java對腳本語言支持的第一階段，今天我們已經實現交付了。
JSR 292——支持Java 平臺上的動態語言是對JSR 223的合理跟進。Java是一門靜態類型的語言。Java中的字節碼需要知道返回類型是什么以及方法調用的參數類型是什么。
開發者在為動態類型語言寫解釋器引擎時，不得不硬造出很多Java類型，以便滿足Java字節碼方法調用的需求。這使得這些解釋器很脆弱：代碼一旦被人改變，要加入并重新設計所有這些硬造出來的類型將很難。而且，它還會降低執行的速度。有趣的是，Java虛擬機并不需要靜態地確定那些類型是什么，只有字節碼才要求這樣。
在JSR 292中，我們將提供一個新的字節碼——invokedynamic。這為Java虛擬機提供了一個方法調用的指令，而無需知道字節碼的返回值和方法參數。這是一個很技術、很官方的解釋，但是它能夠加速Java虛擬機上的解釋器實現，并使它們變得更加健壯。
弗蘭克·索莫斯:您剛才提到invokedynamic將加快動態語言解釋器的執行速度。您能舉個例子嗎？
丹尼·考沃德:假如你現在要獲取一個確定大小的集合（collection），方法的返回類型是Collection。例如，在JRuby中，那種方法可能不需要一個特定的類型返回值就可以得到實現。開發人員可以這樣理解，將要返回的是一個集合，但是并沒有一個特定的返回（值），因為（Ruby）不是一個靜態類型的語言。
動態語言引擎的創造者們在將Ruby代碼轉化為Java字節碼。如果今天的JRuby引擎要將那種方法調用轉化成字節碼，將不得不創建一個合成接口來表現返回類型。這個接口不是由開發人員創建的，而完全是由JRuby引擎創建的，這樣JRuby引擎就可以實現那個方法調用并將它返回成字節碼。這只是返回類型，方法參數和異常的情況是一樣的。
JSR 292則不需要合成接口所需的條件。今天，即便在解釋一段Ruby代碼時，動態語言解釋器的重要性也超出了methodinvoke字節碼。有了 JSR292，他們或許很快就可以使用invokedynamic版本。這將使得引擎實現過程流線化，因為今天的很多引擎都在為硬造新的類型和大量的簿記工作而發愁——如果一個方法在七八個不同的地方被調用，那么在所有的地方將不得不重用那一個硬造的類型。
有趣的是，這不是語言的特征，而是字節碼的特性。Java開發者決不會有意識地去使用JSR 292的一個新特性，因為JSR 292不是一件公開進行的事情。對于新增的字節碼，最令人興奮的地方在于它是第一個不用于Java語言的字節碼。我們打算只將這一字節碼加入Ruby、 Groovy、BeanShell以及Python等語言中。我們非常希望這些語言能夠在Java虛擬機上得到更快的運行。
弗蘭克·索莫斯:那么新增的字節碼能夠在當前版本的Java虛擬機上工作嗎？
丹尼·考沃德:JSR 292的另一方面是調查hot swapping。在很多動態語言中，方法可以在運行時被改變，甚至被添加到一個類。這也是Smalltalk編程最基本的需要。這一想法就是能夠在運行時調整類。
JSR 292是在今年早些時候開始的，我們還不確定它的工作效果如何。不過，這是專家們需要去考慮的問題，這還可能有利于動態解釋器的性能改進。這一特性可能需要對Java虛擬機做一些調整，Java虛擬機也將因此需要做一些變化。專家們還需要注意安全的問題。當然，我們不會在平臺上開放所有的安全漏洞。
弗蘭克·索莫斯:您剛才說到了動態語言的很多優點，那么Java以后會不會變成一種更加動態的語言呢？
丹尼·考沃德:將Java變成一門動態語言，這將是一件很有意思的事情。不過，Java作為一門靜態語言，它擁有很多優勢，如程序的健壯性、可維護性、以及便于向他人發布API的特性。這些優勢都是靜態語言所提供的，我們不想去改變這些。相反，如果能夠讓其他的語言在Java虛擬機上得到更好的運行，那么我們就更沒有必要去改變Java語言了。
我們依然認為，Java語言是用來開發生命力強、可維護且可分享的應用代碼的最佳語言。企業開發的應用軟件需要維持很長一段時間，且部分代碼需要在不同的開發團隊之間甚至在整個社區中分享。對于這些應用軟件，Java自身的特性如靜態類型特征、我們正在研究的模塊性以及包裝結構等，都成就了Java 語言創造出具有頑強生命力的健壯程序。
我們看到，動態語言的使用在設計重心上有些不同，至少程序的部分代碼運行得很快。在這些情況下，能否與其他人共享代碼或能否在時隔六個月之后依然讀懂一段代碼就不再那么重要了。相反，能否快速地生成代碼并迅速寫成一個demo或通過Web再現則變得更加重要了。
我們允許Java開發人員使用動態語言進行部分編程，然后將這部分代碼轉換成Java，或繼續用Java來開發程序中更為健壯、生命力更強的部分，其他代碼則可以通過更加動態的語言來進行開發。這也是JSR 223的重要性所在。在當今社區中，開發者都有不同的語言偏向和愛好。既然如此，他們為什么不可以同時使用Java和Ruby兩種語言呢？
而且，Java發展已過10年，我們對Java所做的變化非常少。我們很清楚，為Java語言增加一些新特性以滿足開發者社區可能出現的每一個需求，這是我們很有可能辦到的事情。但是，如果我們那樣做的話，我們只會使Java變成一門非常復雜的語言，重蹈C++的覆轍。我覺得C++更加注重的是語言的特性而不是簡潔性。
弗蘭克·索莫斯:您說到要使Java虛擬機成為動態語言implementor的理想執行環境，對此您有多大把握？您是否認為Java虛擬機有什么限制因素會阻礙這一任務的實現？
丹尼·考沃德:現在主要的問題是字節碼，因為你不得不硬造出很多類型。這也是JSR 292顯得重要的原因。
當然，從理論上來說，Java虛擬機能成為任何語言解釋器的宿主。很多事情都可能發生，理論是好的，但是實踐更好。關鍵在于讓動態語言能夠在Java虛擬機上真正實現飛快的運行。這也是我們正在努力做的事情。
現在，我們不妨換個角度來看你的問題，比如說如果你是一個動態語言設計師或implementor，你為什么不愿意把Java虛擬機作為您的主要執行平臺？我們已經在這樣一個跨平臺、可擴展的運行時環境上傾注了11年的時間和精力。現在，我們的平臺在行業內得到了廣泛的應用。如果你要創造一門新的動態腳本語言，為什么不選用這樣一個理想的實現平臺呢？難道還有什么比它更好的運行時環境嗎？
我想將來一定會出現一門真正流行的新語言。Java社區尤其是Sun公司很希望看到其他新語言都能夠享受到Java虛擬機所帶來的好處，不管它是什么語言，我們都很樂意這樣做。
51CTO編者后記：在前幾日的JavaOne 2009上也揭示了Java平臺的一些發展方向，其中就包括了JDK 7對動態語言更好的支持：JDK 7中新增了一個字節碼，專門用于令動態語言可以天然在Java平臺上運行。像Groovy，JRuby這樣基于JVM的動態語言都能夠從中獲得好處。真正流行的新語言，或許已經在JVM上奔跑了？
【編輯推薦】
