四种Java脚本语言

 转自：http://blog.csdn.net/widegoose/article/details/306272    

出处 仙人掌工作室　eNet硅谷动力 

一、脚本解释器概述 


在一些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 java set env(TCL_CLASSPATH) set mid [java::new javax.swing.JTree] set f [java::new javax.swing.JFrame] $f setSize 200 200 set 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 swing import java, sys frame = 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无疑是推荐考虑的。 




在本文评测的四种脚本解释器中，Jython是速度最快的一种，拥有一些强大的编程功能。唯一真正令人担心的是Jyphon的流程控制语法，不过，你可能会在乎这些语法上的差异，也可能不会在乎。就象Jacl一样，由于需要学习的新知识比较多，用Jython编写脚本可能需要比JavaScript和BeanShell更长的学习时间。如果你想要用Python编写比较复杂的脚本，就应该买一本书。Python是一种广受欢迎的编程语言，因此可供选择的书籍也相当多。