Java SE 6已不再局限于Java語言了，因為SE 6還可以用來執(zhí)行動態(tài)腳本語言代碼。據(jù)Sun公司Java SE平臺項目的負責人丹尼·考沃德（Danny Coward）稱，Java虛擬機要成為所有動態(tài)語言的最佳執(zhí)行平臺，而提供腳本語言支持只是實現(xiàn)這一計劃的第一步。2006年12月11日，Artima記者弗蘭克·索莫斯（Frank Sommers）就JSR 292——支持Java 平臺上的動態(tài)語言特約采訪了考沃德。

Java SE 6可以加入對Java平臺腳本JSR 223的實現(xiàn)，從而可以被用來執(zhí)行以Ruby、Python、Groovy或者JavaScript等動態(tài)語言編寫的腳本語言代碼。但是，丹尼·考沃德認為， Java虛擬機是專門為靜態(tài)語言而設計的，要在這樣一個平臺上實現(xiàn)動態(tài)語言解釋器絕非易事。考沃德是Sun公司Java SE平臺項目的負責人、JSR 292規(guī)范的主要制訂者。

在Sun即將發(fā)布Java SE 6之前，Artima記者和考沃德進行了一次訪談，其中談到了Java虛擬機動態(tài)語言支持的未來、invokedynamic——一個專用來設計對動態(tài)語言對象的支持的新JVM 指令、運行時改變或添加類方法的hot-swapping，以及將Java虛擬機變?yōu)閯討B(tài)語言實現(xiàn)理想平臺的目標。

弗蘭克·索莫斯 : Java SE 6最大的特征之一就是對動態(tài)語言的支持。您能向我們描述一下在現(xiàn)有的Java SE版本中，這一目標將得到怎樣的實現(xiàn)？今后還會增加哪些對動態(tài)語言的支持？

丹尼·考沃德: 在過去的幾年里，我們已經(jīng)注意到了一種現(xiàn)象。和.NET開發(fā)者社區(qū)不同，Java開發(fā)者社區(qū)早已經(jīng)開始體驗動態(tài)語言了。動態(tài)語言逐漸成為許多開發(fā)者Java應用開發(fā)日常工作的一部分，并常常用于原型開發(fā)（prototyping）或用來提高開發(fā)速度。為了快速得到更大規(guī)模的（Java）應用程序，人們一直在使用動態(tài)語言膠合程序部件。

今天，Java平臺的腳本JSR 223將與Java SE 6一起發(fā)布。在聚集動態(tài)語言愛好者這一方面，JSR 223邁出了它的第一步。首先，它為開發(fā)者提供了允許將其它語言的代碼與Java代碼混合起來的API。其次，JSR 223還是一個框架，它允許開發(fā)者插入用來解釋動態(tài)語言的腳本引擎。在Java SE 6中，我們增加了Rhino JavaScript引擎，這樣非傳統(tǒng)的開發(fā)人員也可以使用JavaScript。

開發(fā)者也可以使用腳本引擎的框架來插入自己的解釋器引擎。我們已經(jīng)從scripting.dev.java.net 上的java.net腳本項目中收集了二十多種動態(tài)語言引擎。這是Java對腳本語言支持的第一階段，今天我們已經(jīng)實現(xiàn)交付了。

JSR 292——支持Java 平臺上的動態(tài)語言是對JSR 223的合理跟進。Java是一門靜態(tài)類型的語言。Java中的字節(jié)碼需要知道返回類型是什么以及方法調用的參數(shù)類型是什么。

開發(fā)者在為動態(tài)類型語言寫解釋器引擎時，不得不硬造出很多Java類型，以便滿足Java字節(jié)碼方法調用的需求。這使得這些解釋器很脆弱：代碼一旦被人改變，要加入并重新設計所有這些硬造出來的類型將很難。而且，它還會降低執(zhí)行的速度。有趣的是，Java虛擬機并不需要靜態(tài)地確定那些類型是什么，只有字節(jié)碼才要求這樣。

在JSR 292中，我們將提供一個新的字節(jié)碼——invokedynamic。這為Java虛擬機提供了一個方法調用的指令，而無需知道字節(jié)碼的返回值和方法參數(shù)。這是一個很技術、很官方的解釋，但是它能夠加速Java虛擬機上的解釋器實現(xiàn)，并使它們變得更加健壯。

弗蘭克·索莫斯:您剛才提到invokedynamic將加快動態(tài)語言解釋器的執(zhí)行速度。您能舉個例子嗎？

丹尼·考沃德:假如你現(xiàn)在要獲取一個確定大小的集合（collection），方法的返回類型是Collection。例如，在JRuby中，那種方法可能不需要一個特定的類型返回值就可以得到實現(xiàn)。開發(fā)人員可以這樣理解，將要返回的是一個集合，但是并沒有一個特定的返回（值），因為（Ruby）不是一個靜態(tài)類型的語言。

動態(tài)語言引擎的創(chuàng)造者們在將Ruby代碼轉化為Java字節(jié)碼。如果今天的JRuby引擎要將那種方法調用轉化成字節(jié)碼，將不得不創(chuàng)建一個合成接口來表現(xiàn)返回類型。這個接口不是由開發(fā)人員創(chuàng)建的，而完全是由JRuby引擎創(chuàng)建的，這樣JRuby引擎就可以實現(xiàn)那個方法調用并將它返回成字節(jié)碼。這只是返回類型，方法參數(shù)和異常的情況是一樣的。

JSR 292則不需要合成接口所需的條件。今天，即便在解釋一段Ruby代碼時，動態(tài)語言解釋器的重要性也超出了methodinvoke字節(jié)碼。有了JSR292，他們或許很快就可以使用invokedynamic版本。這將使得引擎實現(xiàn)過程流線化，因為今天的很多引擎都在為硬造新的類型和大量的簿記工作而發(fā)愁——如果一個方法在七八個不同的地方被調用，那么在所有的地方將不得不重用那一個硬造的類型。

有趣的是，這不是語言的特征，而是字節(jié)碼的特性。Java開發(fā)者決不會有意識地去使用JSR 292的一個新特性，因為JSR 292不是一件公開進行的事情。對于新增的字節(jié)碼，最令人興奮的地方在于它是第一個不用于Java語言的字節(jié)碼。我們打算只將這一字節(jié)碼加入Ruby、Groovy、BeanShell以及Python等語言中。我們非常希望這些語言能夠在Java虛擬機上得到更快的運行。

弗蘭克·索莫斯:那么新增的字節(jié)碼能夠在當前版本的Java虛擬機上工作嗎？

丹尼·考沃德:JSR 292的另一方面是調查hot swapping。在很多動態(tài)語言中，方法可以在運行時被改變，甚至被添加到一個類。這也是Smalltalk編程最基本的需要。這一想法就是能夠在運行時調整類。

JSR 292是在今年早些時候開始的，我們還不確定它的工作效果如何。不過，這是專家們需要去考慮的問題，這還可能有利于動態(tài)解釋器的性能改進。這一特性可能需要對Java虛擬機做一些調整，Java虛擬機也將因此需要做一些變化。專家們還需要注意安全的問題。當然，我們不會在平臺上開放所有的安全漏洞。

弗蘭克·索莫斯:您剛才說到了動態(tài)語言的很多優(yōu)點，那么Java以后會不會變成一種更加動態(tài)的語言呢？

丹尼·考沃德:將Java變成一門動態(tài)語言，這將是一件很有意思的事情。不過，Java作為一門靜態(tài)語言，它擁有很多優(yōu)勢，如程序的健壯性、可維護性、以及便于向他人發(fā)布API的特性。這些優(yōu)勢都是靜態(tài)語言所提供的，我們不想去改變這些。相反，如果能夠讓其他的語言在Java虛擬機上得到更好的運行，那么我們就更沒有必要去改變Java語言了。

我們依然認為，Java語言是用來開發(fā)生命力強、可維護且可分享的應用代碼的最佳語言。企業(yè)開發(fā)的應用軟件需要維持很長一段時間，且部分代碼需要在不同的開發(fā)團隊之間甚至在整個社區(qū)中分享。對于這些應用軟件，Java自身的特性如靜態(tài)類型特征、我們正在研究的模塊性以及包裝結構等，都成就了Java語言創(chuàng)造出具有頑強生命力的健壯程序。

我們看到，動態(tài)語言的使用在設計重心上有些不同，至少程序的部分代碼運行得很快。在這些情況下，能否與其他人共享代碼或能否在時隔六個月之后依然讀懂一段代碼就不再那么重要了。相反，能否快速地生成代碼并迅速寫成一個demo或通過Web再現(xiàn)則變得更加重要了。

我們允許Java開發(fā)人員使用動態(tài)語言進行部分編程，然后將這部分代碼轉換成Java，或繼續(xù)用Java來開發(fā)程序中更為健壯、生命力更強的部分，其他代碼則可以通過更加動態(tài)的語言來進行開發(fā)。這也是JSR 223的重要性所在。在當今社區(qū)中，開發(fā)者都有不同的語言偏向和愛好。既然如此，他們?yōu)槭裁床豢梢酝瑫r使用Java和Ruby兩種語言呢？

而且，Java發(fā)展已過10年，我們對Java所做的變化非常少。我們很清楚，為Java語言增加一些新特性以滿足開發(fā)者社區(qū)可能出現(xiàn)的每一個需求，這是我們很有可能辦到的事情。但是，如果我們那樣做的話，我們只會使Java變成一門非常復雜的語言，重蹈C++的覆轍。我覺得C++更加注重的是語言的特性而不是簡潔性。

弗蘭克·索莫斯:您說到要使Java虛擬機成為動態(tài)語言implementor的理想執(zhí)行環(huán)境，對此您有多大把握？您是否認為Java虛擬機有什么限制因素會阻礙這一任務的實現(xiàn)？

丹尼·考沃德:現(xiàn)在主要的問題是字節(jié)碼，因為你不得不硬造出很多類型。這也是JSR 292顯得重要的原因。

當然，從理論上來說，Java虛擬機能成為任何語言解釋器的宿主。很多事情都可能發(fā)生，理論是好的，但是實踐更好。關鍵在于讓動態(tài)語言能夠在Java虛擬機上真正實現(xiàn)飛快的運行。這也是我們正在努力做的事情。

現(xiàn)在，我們不妨換個角度來看你的問題，比如說如果你是一個動態(tài)語言設計師或implementor，你為什么不愿意把Java虛擬機作為您的主要執(zhí)行平臺？我們已經(jīng)在這樣一個跨平臺、可擴展的運行時環(huán)境上傾注了11年的時間和精力。現(xiàn)在，我們的平臺在行業(yè)內得到了廣泛的應用。如果你要創(chuàng)造一門新的動態(tài)腳本語言，為什么不選用這樣一個理想的實現(xiàn)平臺呢？難道還有什么比它更好的運行時環(huán)境嗎？

我想將來一定會出現(xiàn)一門真正流行的新語言。Java社區(qū)尤其是Sun公司很希望看到其他新語言都能夠享受到Java虛擬機所帶來的好處，不管它是什么語言，我們都很樂意這樣做。