四種Java腳本語言之評(píng)測(cè)

zqm6666

四種Java腳本語言之評(píng)測(cè)
一、腳本解釋器概述
　　
　　
　　在一些Java應(yīng)用的需求中，集成某種腳本語言的支持能夠帶來很大的方便。例如，用戶可能想要編寫腳本程序驅(qū)動(dòng)應(yīng)用、擴(kuò)展應(yīng)用，或?yàn)榱撕?jiǎn)化操作而編寫循環(huán)和其他流程控制邏輯。在這些情況下，一種理想的解決方案是在Java應(yīng)用中提供對(duì)腳本語言解釋器的支持，讓腳本語言解釋器讀取用戶編寫的腳本并在應(yīng)用提供的類上運(yùn)行這些腳本。為了實(shí)現(xiàn)這個(gè)目標(biāo)，你可以在Java應(yīng)用所運(yùn)行的JVM中，運(yùn)行一個(gè)基于Java的腳本語言解釋器。
　　
　　
　　一些支持庫，例如IBM的Bean Scripting Framework，能夠幫助你把不同的腳本語言集成到Java程序。這些支持框架能夠讓你的Java應(yīng)用在不作大量修改的情況下，運(yùn)行Tcl、Python和其他語言編寫的腳本。
　　
　　
　　在Java應(yīng)用中集成了腳本解釋器之后，用戶編寫的腳本能夠直接引用Java應(yīng)用的類，就如這些腳本屬于Java程序的一部分一樣。這種思路既有優(yōu)點(diǎn)也有缺點(diǎn)。其優(yōu)點(diǎn)在于，如果你想要用腳本驅(qū)動(dòng)的方式對(duì)應(yīng)用進(jìn)行回歸測(cè)試，或者想要通過腳本對(duì)應(yīng)用進(jìn)行低級(jí)調(diào)用，它能夠帶來很大的方便；其缺點(diǎn)在于，如果用戶的腳本直接操作Java程序的內(nèi)部結(jié)構(gòu)而不是經(jīng)過認(rèn)可的API，它可能影響Java程序的完整性和應(yīng)用的安全。因此，應(yīng)當(dāng)仔細(xì)地規(guī)劃那些允許用戶針對(duì)其編寫腳本的API，并聲明程序的其余部分不允許用腳本操作。另外，你還可以對(duì)那些不想讓用戶針對(duì)其進(jìn)行腳本編程的類和方法名稱進(jìn)行模糊處理，只留出那些允許腳本編程的API類和方法名字。這樣，你就能夠有效地降低喜歡冒險(xiǎn)的用戶直接用腳本操作受保護(hù)的類和方法的可能性。
　　
　　
　　在Java程序中支持多種腳本語言有著非同尋常的意義，但如果你正在編寫的是一個(gè)商業(yè)應(yīng)用，則應(yīng)當(dāng)慎重考慮――盡管你為用戶提供了最完善的功能，但同時(shí)也帶來了最多的出錯(cuò)機(jī)會(huì)。必須考慮到配置和管理問題，因?yàn)橹辽儆幸徊糠值哪_本解釋器在定期地進(jìn)行升級(jí)和更新，這樣你就必須花很大的力氣管理各個(gè)解釋器的哪些版本適合于Java應(yīng)用的哪些版本。如果用戶為了解決舊腳本解釋器中存在的BUG，對(duì)其中某個(gè)腳本解釋器進(jìn)行了升級(jí)，你的Java應(yīng)用就會(huì)運(yùn)行在一種未經(jīng)完全測(cè)試的配置下。數(shù)天或數(shù)星期之后，用戶也許會(huì)發(fā)現(xiàn)由于腳本引擎升級(jí)而產(chǎn)生的問題，但他們很可能不會(huì)把腳本引擎升級(jí)的事情告訴你，這時(shí)你就很難再次重復(fù)試驗(yàn)出用戶報(bào)告的錯(cuò)誤了。
　　
　　
　　另外，用戶很可能堅(jiān)持認(rèn)為你必須為Java應(yīng)用支持的腳本解釋器提供補(bǔ)丁。一些腳本解釋器按照源代碼開放的模式及時(shí)進(jìn)行維護(hù)和更新；對(duì)于這些腳本解釋器，可能有專家?guī)椭�你解決問題、修補(bǔ)解釋器，或在新的發(fā)行版中引入補(bǔ)丁。這是很重要的，因?yàn)槟_本解釋器是一個(gè)很復(fù)雜的工具，包含大量的代碼，如果沒有專家的支持，對(duì)于自己修改腳本解釋器這一令人煩惱的任務(wù)，你很可能束手無策。
　　
　　
　　為了避免出現(xiàn)這種問題，你應(yīng)該對(duì)于每一種準(zhǔn)備在Java應(yīng)用中提供支持的腳本解釋器進(jìn)行全面的測(cè)試。對(duì)于每一種解釋器，確保它能夠順利地處理絕大多數(shù)常見的使用情形，確保它即使在極端苛刻的條件下運(yùn)行大量的腳本也不會(huì)出現(xiàn)大的內(nèi)存漏洞，確保當(dāng)你對(duì)Java程序和腳本解釋器進(jìn)行嚴(yán)格的Beta測(cè)試時(shí)不會(huì)出現(xiàn)任何意外的情況。當(dāng)然，這種前期測(cè)試需要投入時(shí)間和其他資源；但不管怎樣，測(cè)試投入總是物有所值的。 二、保持系統(tǒng)簡(jiǎn)潔
　　
　　
　　如果你必須在Java應(yīng)用中提供腳本支持，首先必須選擇一個(gè)最符合應(yīng)用要求和用戶基礎(chǔ)的腳本解釋器。選擇合適的解釋器能夠簡(jiǎn)化集成解釋器的代碼，減少客戶支持方面的支出，以及提高應(yīng)用的穩(wěn)定性。最困難的問題在于：如果只能選用一種解釋器，應(yīng)該選用哪一種呢？
　　
　　
　　我比較了幾種腳本解釋器，開始時(shí)考慮的腳本語言包括Tcl、Python、Perl、JavaScript和BeanShell。接著，在深入分析之前，我放棄了Perl。為什么呢？因?yàn)镻erl沒有用Java寫的解釋器。假設(shè)你選擇了一個(gè)用本機(jī)代碼實(shí)現(xiàn)的腳本解釋器，例如Perl，則Java應(yīng)用和腳本代碼之間的交互就不再直接進(jìn)行；另外，對(duì)于每一個(gè)你想要支持的操作系統(tǒng)，都必須提供一個(gè)腳本解釋器的二進(jìn)制代碼庫。由于許多開發(fā)者選擇Java是因?yàn)榭粗辛怂�的跨平臺(tái)可移植性，為了保證Java應(yīng)用有這種優(yōu)點(diǎn)，所以最好選擇一種不依賴于本機(jī)代碼的解釋器。和Perl不同，Tcl、Python、JavaScript和BeanShell都有基于Java的解釋器，所以這些語言的代碼可以與Java應(yīng)用在同一個(gè)JVM和進(jìn)程之內(nèi)運(yùn)行。
　　
　　
　　基于以上標(biāo)準(zhǔn)，參與本文評(píng)測(cè)的腳本解釋器包括：
　　
　　
　　
　　
　　
　　Jacl：Tcl的Java實(shí)現(xiàn)。
　　
　　
　　Jython：Python的Java實(shí)現(xiàn)。
　　
　　
　　Rhino：JavaScript的Java實(shí)現(xiàn)。
　　
　　
　　BeanShell：一個(gè)用Java編寫的Java源代碼解釋器。
　　
　　
　　
　　
　　限定了待比較的解釋器種類之后，接下來就可以從各個(gè)方面對(duì)它們進(jìn)行比較了。
　　
　　
　　三、評(píng)測(cè)之一：可用性
　　
　　
　　第一個(gè)評(píng)測(cè)項(xiàng)目是可用性。這項(xiàng)評(píng)測(cè)分析了是否存在某種解釋器不可用的情形。用每一種語言各編寫一個(gè)簡(jiǎn)單的測(cè)試程序，然后分別用相應(yīng)的解釋器運(yùn)行，結(jié)果發(fā)現(xiàn)，所有解釋器都通過了測(cè)試，每一種解釋器都能夠穩(wěn)定地工作或能夠方便地與之交互。既然每一種解釋器都值得考慮，那么，有哪些因素可能使開發(fā)者偏愛其中一種呢？
　　
　　
　　
　　
　　
　　Jacl：如果你想要在Tk腳本代碼中創(chuàng)建用戶界面元素，請(qǐng)?jiān)L問Swank project，它把Java的Swing部件封裝到了Tk里面。發(fā)行版不包含Jacl腳本的調(diào)試器。
　　
　　
　　Jython：支持用Python語法編寫的腳本。Python利用縮進(jìn)層次表示代碼塊的結(jié)構(gòu)，而不是象其他許多語言一樣用花括號(hào)或開始-結(jié)束符號(hào)表示控制流程。至于這種改變究竟是好事還是壞事，這就要看你和用戶的習(xí)慣了。發(fā)行版不包含Jython腳本的調(diào)試器。
　　
　　
　　Rhino：許多程序員總是把JavaScript和Web頁面編程關(guān)聯(lián)起來，但這個(gè)版本的JavaScript不需要在瀏覽器中運(yùn)行。在使用過程中，我沒有發(fā)現(xiàn)任何問題。它的發(fā)行版帶有一個(gè)簡(jiǎn)單但實(shí)用的腳本調(diào)試器。
　　
　　
　　BeanShell：Java程序員很快會(huì)對(duì)這個(gè)源代碼解釋器產(chǎn)生一種親切的感覺。BeanShell的文檔寫得很不錯(cuò)，但開發(fā)組很小。然而，只有當(dāng)BeanShell的開發(fā)者改變了他們的興趣，卻又沒有其他人填補(bǔ)他們轉(zhuǎn)換興趣后留下的空白時(shí)，開發(fā)組太小才會(huì)成為一個(gè)問題。它的發(fā)行版不包含BeanShell腳本調(diào)試器。
　　
　　四、評(píng)測(cè)之二：性能
　　
　　
　　第二個(gè)評(píng)測(cè)項(xiàng)目是性能。這項(xiàng)測(cè)試是要分析各個(gè)腳本解釋器執(zhí)行一些簡(jiǎn)單程序的速度。本次測(cè)試沒有要求解釋器排序大型數(shù)組，也沒有執(zhí)行復(fù)雜的數(shù)學(xué)計(jì)算，而是執(zhí)行了一些簡(jiǎn)單的、常見的操作，例如循環(huán)、整數(shù)比較，以及分配和初始化大型數(shù)組和二維數(shù)組。測(cè)試程序都很簡(jiǎn)單，且這些操作都是每一個(gè)商業(yè)應(yīng)用或多或少要用到的。另外，本項(xiàng)測(cè)試還分析了每一個(gè)解釋器初始化和執(zhí)行簡(jiǎn)單腳本所需要的內(nèi)存。
　　
　　
　　為一致起見，測(cè)試程序的每一種腳本語言的版本都盡量地相似。測(cè)試在一臺(tái)Toshiba Tecra 8100筆記本上進(jìn)行，CPU是700-MHz的Pentium III處理器，RAM是256 MB。調(diào)用JVM時(shí)，堆棧大小使用默認(rèn)值。
　　
　　
　　為了便于理解和比較腳本程序的執(zhí)行速度，本項(xiàng)評(píng)測(cè)還在Java 1.3.1下運(yùn)行了類似功能的Java程序，又在Tcl本機(jī)解釋器內(nèi)運(yùn)行了為Jacl腳本解釋器編寫的Tcl腳本。因此，在下面的表格中，你還可以看到這兩次測(cè)試的結(jié)果。
　　
　　
　　表一：從1到1000000計(jì)數(shù)的for循環(huán)：
　　　


　　表二：比較整數(shù)是否相等，1000000次：
　　　


　　表三：分配并初始化100000個(gè)元素的數(shù)組：
　　　


　　表四：分配并初始化500 X 500 個(gè)元素的數(shù)組：
　　　


　　表五：在JVM內(nèi)初始化解釋器所需要的內(nèi)存：
　　

　　本項(xiàng)評(píng)測(cè)證明Jython具有最好的性能，與其他解釋器拉開了相當(dāng)可觀的差距，Rhino第二，BeanShell稍慢，而Jacl墊底。然而，對(duì)于你來說，這些性能數(shù)據(jù)到底能夠產(chǎn)生多大的影響，這與你想要用腳本語言完成的任務(wù)密切相關(guān)。如果腳本函數(shù)中包含大量的迭代操作，那么Jacl或BeanShell可能是令人難以接受的。如果腳本程序重復(fù)執(zhí)行代碼的機(jī)會(huì)很少，那么這些解釋器在速度上的相對(duì)差異就不那么重要了。值得指出的是，Jython看來沒有為聲明二維數(shù)組提供內(nèi)建的直接支持，但這個(gè)問題可以通過一個(gè)“數(shù)組的數(shù)組”結(jié)構(gòu)解決。
　　五、評(píng)測(cè)之三：集成的難易程度
　　
　　
　　本項(xiàng)評(píng)測(cè)包含兩個(gè)任務(wù)。第一個(gè)任務(wù)是比較對(duì)各種腳本語言解釋器進(jìn)行實(shí)例化時(shí)需要多少代碼；第二個(gè)任務(wù)是編寫一個(gè)完成如下操作的腳本：實(shí)例化一個(gè)Java JFrame，放入一個(gè)JTree，調(diào)整大小并顯示出JFrame。盡管這些任務(wù)都很簡(jiǎn)單，但由此我們可以看出開始使用一個(gè)解釋器要做多少工作，還可以看出為解釋器編寫的腳本代碼在調(diào)用Java類時(shí)到底是什么樣子。
　　
　　
　　■　Jacl
　　
　　
　　要把Jacl集成到Java應(yīng)用，首先要把Jacl的Jar文件加入到Java的CLASSPATH，然后在執(zhí)行腳本之前，創(chuàng)建Jacl解釋器的實(shí)例。下面是創(chuàng)建Jacl解釋器實(shí)例的代碼：
　　
　　
　　
　　import tcl.lang.*;
　　
　　public class SimpleEmbedded {
　　public static void main(String args[]) {
　　　try {
　　　　Interp interp = new Interp();
　　　} catch (Exception e) {


本文來自ChinaUnix博客，如果查看原文請(qǐng)點(diǎn)：http://blog.chinaunix.net/u/26836/showart_328143.html