四種Java腳本語言對比的示例分析

小編給大家分享一下四種Java腳本語言對比的示例分析，相信大部分人都還不怎么了解，因此分享這篇文章給大家參考一下，希望大家閱讀完這篇文章后大有收獲，下面讓我們一起去了解一下吧！

在一些Java應用的需求中，集成某種腳本語言的支持能夠帶來很大的方便。例如，用戶可能想要編寫腳本程序驅動應用、擴展應用，或為了簡化操作而編寫循環和其他流程控制邏輯。在這些情況下，一種理想的解決方案是在Java應用中提供對腳本語言解釋器的支持，讓腳本語言解釋器讀取用戶編寫的腳本并在應用提供的類上運行這些腳本。為了實現這個目標，你可以在Java應用所運行的JVM中，運行一個基于Java的腳本語言解釋器。


一些支持庫，例如IBM的Bean Scripting Framework，能夠幫助你把不同的腳本語言集成到Java程序。這些支持框架能夠讓你的Java應用在不作大量修改的情況下，運行Tcl、Python和其他語言編寫的腳本。


在Java應用中集成了腳本解釋器之后，用戶編寫的腳本能夠直接引用Java應用的類，就如這些腳本屬于Java程序的一部分一樣。這種思路既有優點也有缺點。其優點在于，如果你想要用腳本驅動的方式對應用進行回歸測試，或者想要通過腳本對應用進行低級調用，它能夠帶來很大的方便；其缺點在于，如果用戶的腳本直接操作Java程序的內部結構而不是經過認可的API，它可能影響Java程序的完整性和應用的安全。因此，應當仔細地規劃那些允許用戶針對其編寫腳本的API，并聲明程序的其余部分不允許用腳本操作。另外，你還可以對那些不想讓用戶針對其進行腳本編程的類和方法名稱進行模糊處理，只留出那些允許腳本編程的API類和方法名字。這樣，你就能夠有效地降低喜歡冒險的用戶直接用腳本操作受保護的類和方法的可能性。


在Java程序中支持多種腳本語言有著非同尋常的意義，但如果你正在編寫的是一個商業應用，則應當慎重考慮——盡管你為用戶提供了最完善的功能，但同時也帶來了最多的出錯機會。必須考慮到配置和管理問題，因為至少有一部分的腳本解釋器在定期地進行升級和更新，這樣你就必須花很大的力氣管理各個解釋器的哪些版本適合于Java應用的哪些版本。如果用戶為了解決舊腳本解釋器中存在的BUG，對其中某個腳本解釋器進行了升級，你的Java應用就會運行在一種未經完全測試的配置下。數天或數星期之后，用戶也許會發現由于腳本引擎升級而產生的問題，但他們很可能不會把腳本引擎升級的事情告訴你，這時你就很難再次重復試驗出用戶報告的錯誤了。


另外，用戶很可能堅持認為你必須為Java應用支持的腳本解釋器提供補丁。一些腳本解釋器按照源代碼開放的模式及時進行維護和更新；對于這些腳本解釋器，可能有專家幫助你解決問題、修補解釋器，或在新的發行版中引入補丁。這是很重要的，因為腳本解釋器是一個很復雜的工具，包含大量的代碼，如果沒有專家的支持，對于自己修改腳本解釋器這一令人煩惱的任務，你很可能束手無策。


為了避免出現這種問題，你應該對于每一種準備在Java應用中提供支持的腳本解釋器進行全面的測試。對于每一種解釋器，確保它能夠順利地處理絕大多數常見的使用情形，確保它即使在極端苛刻的條件下運行大量的腳本也不會出現大的內存漏洞，確保當你對Java程序和腳本解釋器進行嚴格的Beta測試時不會出現任何意外的情況。當然，這種前期測試需要投入時間和其他資源；但不管怎樣，測試投入總是物有所值的。
二、保持系統簡潔


如果你必須在Java應用中提供腳本支持，首先必須選擇一個最符合應用要求和用戶基礎的腳本解釋器。選擇合適的解釋器能夠簡化集成解釋器的代碼，減少客戶支持方面的支出，以及提高應用的穩定性。最困難的問題在于：如果只能選用一種解釋器，應該選用哪一種呢？


我比較了幾種腳本解釋器，開始時考慮的腳本語言包括Tcl、Python、Perl、JavaScript和BeanShell。接著，在深入分析之前，我放棄了Perl。為什么呢？因為Perl沒有用Java寫的解釋器。假設你選擇了一個用本機代碼實現的腳本解釋器，例如Perl，則Java應用和腳本代碼之間的交互就不再直接進行；另外，對于每一個你想要支持的操作系統，都必須提供一個腳本解釋器的二進制代碼庫。由于許多開發者選擇Java是因為看中了它的跨平臺可移植性，為了保證Java應用有這種優點，所以最好選擇一種不依賴于本機代碼的解釋器。和Perl不同，Tcl、Python、JavaScript和BeanShell都有基于Java的解釋器，所以這些語言的代碼可以與Java應用在同一個JVM和進程之內運行。


基于以上標準，參與本文評測的腳本解釋器包括：





Jacl：Tcl的Java實現。


Jython：Python的Java實現。


Rhino：JavaScript的Java實現。


BeanShell：一個用Java編寫的Java源代碼解釋器。




限定了待比較的解釋器種類之后，接下來就可以從各個方面對它們進行比較了。


三、評測之一：可用性


第一個評測項目是可用性。這項評測分析了是否存在某種解釋器不可用的情形。用每一種語言各編寫一個簡單的測試程序，然后分別用相應的解釋器運行，結果發現，所有解釋器都通過了測試，每一種解釋器都能夠穩定地工作或能夠方便地與之交互。既然每一種解釋器都值得考慮，那么，有哪些因素可能使開發者偏愛其中一種呢？





Jacl：如果你想要在Tk腳本代碼中創建用戶界面元素，請訪問Swank project，它把Java的Swing部件封裝到了Tk里面。發行版不包含Jacl腳本的調試器。


Jython：支持用Python語法編寫的腳本。Python利用縮進層次表示代碼塊的結構，而不是象其他許多語言一樣用花括號或開始-結束符號表示控制流程。至于這種改變究竟是好事還是壞事，這就要看你和用戶的習慣了。發行版不包含Jython腳本的調試器。


Rhino：許多程序員總是把JavaScript和Web頁面編程關聯起來，但這個版本的JavaScript不需要在瀏覽器中運行。在使用過程中，我沒有發現任何問題。它的發行版帶有一個簡單但實用的腳本調試器。


BeanShell：Java程序員很快會對這個源代碼解釋器產生一種親切的感覺。BeanShell的文檔寫得很不錯，但開發組很小。然而，只有當BeanShell的開發者改變了他們的興趣，卻又沒有其他人填補他們轉換興趣后留下的空白時，開發組太小才會成為一個問題。它的發行版不包含BeanShell腳本調試器。

四、評測之二：性能


第二個評測項目是性能。這項測試是要分析各個腳本解釋器執行一些簡單程序的速度。本次測試沒有要求解釋器排序大型數組，也沒有執行復雜的數學計算，而是執行了一些簡單的、常見的操作，例如循環、整數比較，以及分配和初始化大型數組和二維數組。測試程序都很簡單，且這些操作都是每一個商業應用或多或少要用到的。另外，本項測試還分析了每一個解釋器初始化和執行簡單腳本所需要的內存。


為一致起見，測試程序的每一種腳本語言的版本都盡量地相似。測試在一臺Toshiba Tecra 8100筆記本上進行，CPU是700-MHz的Pentium III處理器，RAM是256 MB。調用JVM時，堆棧大小使用默認值。


為了便于理解和比較腳本程序的執行速度，本項評測還在Java 1.3.1下運行了類似功能的Java程序，又在Tcl本機解釋器內運行了為Jacl腳本解釋器編寫的Tcl腳本。因此，在下面的表格中，你還可以看到這兩次測試的結果。

表格一：從1到1000000計數的for循環：

解釋器類型　 時間
-----------------------
Java 10 毫秒
Tcl 1.4 秒
Jacl 140 秒
Jython 1.2 秒
Rhino 5 秒
BeanShell 80 秒
--------------------

表格二：比較整數是否相等，1000000次：

解釋器類型 時間
-----------------------
Java 10 毫秒
Tcl 2 秒
Jacl 300 秒
Jython 4 秒
Rhino 8 秒
BeanShell 80 秒
--------------------

表格三：分配并初始化100000個元素的數組：

解釋器類型 時間
-----------------------
Java 10 毫秒
Tcl .5 秒
Jacl 25 秒
Jython 1 秒
Rhino 1.3 秒
BeanShell 22 秒
--------------------

表格四：分配并初始化500 X 500 個元素的數組：

解釋器類型　 時間
--------------------
Java 20 毫秒
Tcl 2 秒
Jacl 45 秒
Jython 1 秒
Rhino 7 秒
BeanShell 18 秒
--------------------

表格五：在JVM內初始化解釋器所需要的內存：

解釋器類型　 內存占用
----------------------
Jacl 大約 1 MB
Jython 大約 2 MB
Rhino 大約 1 MB
BeanShell 大約 1 MB
----------------------


本項評測證明Jython具有最好的性能，與其他解釋器拉開了相當可觀的差距，Rhino第二，BeanShell稍慢，而Jacl墊底。然而，對于你來說，這些性能數據到底能夠產生多大的影響，這與你想要用腳本語言完成的任務密切相關。如果腳本函數中包含大量的迭代操作，那么Jacl或BeanShell可能是令人難以接受的。如果腳本程序重復執行代碼的機會很少，那么這些解釋器在速度上的相對差異就不那么重要了。值得指出的是，Jython看來沒有為聲明二維數組提供內建的直接支持，但這個問題可以通過一個“數組的數組”結構解決。

五、評測之三：集成的難易程度


本項評測包含兩個任務。第一個任務是比較對各種腳本語言解釋器進行實例化時需要多少代碼；第二個任務是編寫一個完成如下操作的腳本：實例化一個Java JFrame，放入一個JTree，調整大小并顯示出JFrame。盡管這些任務都很簡單，但由此我們可以看出開始使用一個解釋器要做多少工作，還可以看出為解釋器編寫的腳本代碼在調用Java類時到底是什么樣子。


■　Jacl

要把Jacl集成到Java應用，首先要把Jacl的Jar文件加入到Java的CLASSPATH，然后在執行腳本之前，創建Jacl解釋器的實例。下面是創建Jacl解釋器實例的代碼：



import tcl.lang.*;public class SimpleEmbedded { public static void main(String args[]) { try { Interp interp = new Interp(); } catch (Exception e) { }}


下面的Jacl腳本代碼顯示了如何創建一個JTree，把它放入JFrame，調整大小并顯示JFrame：



package require javaset env(TCL_CLASSPATH) set mid [java::new javax.swing.JTree]set f [java::new javax.swing.JFrame]$f setSize 200 200set layout [java::new java.awt.BorderLayout]$f setLayout $layout$f add $mid $f show



■　Jython

要把Jython集成到Java應用，首先要把Jython的Jar文件加入到Java的CLASSPATH，然后在執行腳本之前，創建一個Jython解釋器的實例。完成這個任務的代碼很簡單：



import org.python.util.PythonInterpreter;import org.python.core.*;public class SimpleEmbedded { public static void main(String []args) throws PyException { PythonInterpreter interp = new PythonInterpreter(); }}


下面的Jython腳本代碼顯示了如何創建JTree，把它放入JFrame，然后顯示出JFrame。下面的代碼不包含調整大小的操作：



from pawt import swingimport java, sysframe = swing.JFrame('Jython example', visible=1)tree = swing.JTree()frame.contentPane.add(tree)frame.pack()


■　Rhino


和其他解釋器一樣，集成Rhino時首先要把Rhino的Jar文件加入到Java的CLASSPATH，然后在執行腳本之前，創建Rhino解釋器的實例：



import org.mozilla.javascript.*;import org.mozilla.javascript.tools.ToolErrorReporter;public class SimpleEmbedded { public static void main(String args[]) { Context cx = Context.enter(); }}


下面簡單的Rhino腳本顯示了如何創建JTree，把它放入JFrame，調整大小并顯示出JFrame：



importPackage(java.awt);importPackage(Packages.javax.swing);frame = new Frame("JavaScript");frame.setSize(new Dimension(200,200)); frame.setLayout(new BorderLayout());t = new JTree();frame.add(t, BorderLayout.CENTER);frame.pack();frame.show();


■　BeanShell


集成BeanShell也和集成其他解釋器一樣簡單。先把BeanShell的Jar文件加入到Java的CLASSPATH，然后在執行腳本代碼之前創建一個BeanShell解釋器的實例：



import bsh.Interpreter;public class SimpleEmbedded { public static void main(String []args) throws bsh.EvalError { Interpreter i = new Interpreter(); }}


下面的BeanShell腳本代碼顯示了如何創建一個JTree，把它放入JFrame，調整大小并顯示出JFrame。代碼很簡單，且具有熟悉的Java風格：



frame = new JFrame();tree = new JTree();frame.getContentPane().add(tree);frame.pack();frame.show();


從上面的說明可以看出，在Java應用中集成任何一種解釋器都是很容易的。同時，只要你掌握了腳本語言的語法，就能夠高效地編寫出腳本程序。前面幾個簡單的例子顯示出，用BeanShell和JavaScript編寫的腳本在格式上與Java最相似，而Jacl和Jython則顯得有些不同，但Jacl和Jython腳本也不是難以理解的。正如上面為各個腳本解釋器編寫的腳本所顯示的，在腳本代碼和Java應用的類之間不存在任何防火墻。因此必須注意：腳本代碼直接在Java應用的類的基礎上運行。應當確信這就是你想要的效果。如果你想要在運行時對應用的某些部分進行保護，避免腳本代碼訪問某些部分，就應當采取對非公開的代碼進行模糊處理之類的措施，避免人們直接對不公開的API進行編程。

六、評測之四：支持和許可問題


盡管集成腳本解釋器賦予Java應用額外的能力，但同時它也使得Java應用依賴于那些腳本庫。在確定選用某一種腳本解釋器之前，考慮一下將來的某一天你必須修改被集成的代碼的機會。如果腳本解釋器的開發者很少更新或升級解釋器，這不是一個好的跡象。它或者意味著當時的解釋器實現代碼已經很完美，或者負責這些代碼的開發者已經轉移到其他軟件項目上。至于哪一種情況的可能性比較大，答案非常明顯。


另外，還有必要看看實現解釋器需要多少源代碼。試圖掌握解釋器的每一行代碼并對它進行擴展或改進是不切實際的，因為解釋器的代碼規模實在太大了。盡管如此，了解解釋器的規模仍是必要的，因為在某些時候，你可能需要修改解釋器的源代碼，也可能為了掌握解釋器的具體工作原理而需要對解釋器代碼作比較深入的了解。


下面就來看看每一種解釋器的代碼庫支持問題。





Jacl


Jacl有一個活躍的支持和開發組。盡管開發網站上的下載鏈接指向了一個數年前的發行版，但新的版本可通過CVS版本控制系統找到。Jacl包含約37000行Java代碼。


Jython


Jython的支持、維護和更新看起來都很活躍。Jython大約包含55000行Java代碼。


Rhino


Rhino的更新和發行都比較頻繁，它大約包含44000行Java代碼。


BeanShell


BeanShell也定期地進行更新，它大約包含25000行Java代碼，另外還有不少BeanShell腳本提供。





可以看出，所有這些解釋器都很龐大。如果你能夠依賴于解釋器的開發和支持組織提供的改進和BUG補丁，你自己的麻煩就會少一些。在選擇一個解釋器之前，不妨看看解釋器升級和發行是否很頻繁。也許你可以與某個開發者取得聯系，了解他們的長遠計劃以及BUG修正過程。


這些解釋器都是可以免費下載的。然而，如果要把它們嵌入到商業應用之中，它們的許可規則又是怎樣的呢？好在對于所有這些解釋器來說，軟件許可都不存在什么問題。閱讀Jacl、Jython、JavaScript和BeanShell的許可協議可以發現，用戶必須遵從GNU LGP或等價的許可。這就意味著，即使你的Java應用不是免費的，仍舊可以在發布應用時帶上腳本解釋器。但是，你不能刪除源代碼文件和腳本文件中的版權信息，而且還要明確地告訴用戶，與Java應用捆綁在一起的腳本解釋器屬于其他人所有。



七、結束語


如果你打算在Java應用中集成腳本編程支持，我建議你只選用一個腳本解釋器。在你的產品中，每次額外增加一種腳本支持都會帶來相應的代價，因此應該避免在Java應用中集成一種以上的腳本解釋器。為Java應用添加腳本支持時，選用基于Java的解釋器而不是Perl之類的本機解釋器能夠簡化以后的工作，能夠使你的產品具有更好的可移植性，并為Java程序和解釋器的集成工作帶來方便。


如果客戶想要用某種特定的腳本語言來定制你的產品，務必認真地檢查一下如果集成了支持該語言的腳本解釋器是否會出現問題。如果你不必局限于某種特定的腳本語言，則應當從多個不同的角度對解釋器進行比較，看看哪一個更適合Java應用所面臨的主要任務。


例如，與其他解釋器相比，Jacl的發展速度看起來特別慢，但如果你必須使用Tcl腳本，使用Jacl解釋器仍舊是值得的。如果你要把一個應用從Tcl/Tk移植到Java，Jacl使得新的Java應用能夠運行原來的Tcl腳本，這種能力的價值可能超越其他方面的不足。另外，Tcl屬于流行的編程語言，很多開發者已經熟悉它，而且關于Tcl編程的書也容易買到。


如果你喜歡Java風格的腳本代碼，并且力求減少集成過程中的麻煩，BeanShell看來很不錯。它的不足之處是，BeanShell語法和編程方面的用戶指南僅僅局限于發行版所包含的內容，而且BeanShell與其他一些腳本解釋器相比運行速度較慢。另一方面，我覺得BeanShell比較容易使用。BeanShell的庫組織得很好，從而簡化了集成工作。如果你選擇腳本解釋器時性能不是關鍵的考慮因素，那么你可以考慮BeanShell。


Rhino運行速度明顯比BeanShell快，而且它也同樣支持Java風格的腳本。另外，它看起來具有較高的開發質量和支持服務，有關JavaScript語法和編程的書也很容易找到。如果你對性能、Java風格的語法和強大的支持服務有著差不多平衡的需求， Rhino無疑是推薦考慮的。

以上是“四種Java腳本語言對比的示例分析”這篇文章的所有內容，感謝各位的閱讀！相信大家都有了一定的了解，希望分享的內容對大家有所幫助，如果還想學習更多知識，歡迎關注億速云行業資訊頻道！