java语言软件开发工具包是什么(使用java语法的脚本语言)

边肖将与您分享一个比较四种Java脚本语言的示例分析。相信大部分人对它还不太了解，所以我分享这篇文章给大家参考。希望你看完这篇文章能有很多收获。我们一起来看看吧！

在一些Java应用程序中，集成脚本语言的支持可以带来极大的便利。例如，用户可能希望编写脚本来驱动应用程序、扩展应用程序，或者编写循环和其他流控制逻辑来简化操作。在这种情况下，一个理想的解决方案是在Java应用中为脚本语言解释器提供支持，让脚本语言解释器读取用户编写的脚本，并在应用提供的类上运行。为了实现这个目标，您可以在运行Java应用程序的JVM中运行基于Java的脚本语言解释器。

一些支持库，如IBM的Bean脚本框架，可以帮助您将不同的脚本语言集成到Java程序中。这些支持框架使您的Java应用程序能够运行用Tcl、Python和其他语言编写的脚本，而无需进行大量更改。

脚本解释器集成到Java应用程序中后，用户编写的脚本可以直接引用Java应用程序的类，就像这些脚本是Java程序的一部分一样。这个想法有利也有弊。它的优点是，如果你想对应用程序使用脚本驱动的回归测试，或者你想通过脚本对应用程序进行低级调用，可以带来很大的便利。缺点是如果用户的脚本直接操作Java程序的内部结构，而不是经过批准的API，可能会影响Java程序的完整性和应用的安全性。因此，我们应该仔细规划允许用户为其编写脚本的API，并声明程序的其余部分不允许使用脚本进行操作。此外，您可以混淆不希望用户编写脚本的类和方法的名称，只留下那些允许编写脚本的API类和方法名称。通过这种方式，您可以有效地减少冒险用户直接使用脚本来操作受保护的类和方法的可能性。

在Java程序中支持多种脚本语言具有非凡的意义，但是如果您正在编写一个商业应用程序，您应该仔细考虑3354。虽然你为用户提供了最完善的功能，但也带来了最多的出错机会。必须考虑配置和管理问题，因为至少有些脚本解释器是定期升级更新的，所以你必须下大力气去管理每个解释器的哪些版本适合Java应用。如果用户升级其中一个脚本解释器来解决旧脚本解释器中的BUG，那么您的Java应用程序将在未经测试的配置中运行。几天或几周之后，用户可能会发现脚本引擎升级带来的问题，但他们很可能不会告诉你脚本引擎的升级，所以你很难再次尝试用户报告的错误。

此外，用户可能会坚持要求您必须为Java应用程序支持的脚本解释器提供补丁。有的脚本解释器按照开源模式及时维护更新；对于这些脚本解释器，可能会有专家帮助您解决问题，修复解释器，或者在新发行版中引入补丁。这一点非常重要，因为脚本解释器是一个非常复杂的工具，其中包含了大量的代码。如果没有专家的支持，您可能无法自行完成修改脚本解释器的烦人任务。

为了避免这个问题，您应该对准备在Java应用程序中提供支持的每个脚本解释器进行全面的测试。对于每一种解释器，确保它能够成功处理最常见的用例，确保即使它在极其苛刻的条件下运行大量的脚本，也不会出现大的内存泄漏，确保在您严格Beta测试Java程序和脚本解释器时不会出现意外情况。当然，这个预测试需要投入时间等资源；但无论如何，测试投资总是值得的。

第二，保持系统简单

如果您必须在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: Java实现Jython:Python。

rhino:JavaScript的Java实现。

BeanShell:一个用Java编写的Java源代码解释器。

在定义了要比较的口译员类型后，我们可以从各个方面进行比较。

r/>

三、评测之一：可用性

第一个评测项目是可用性。这项评测分析了是否存在某种解释器不可用的情形。用每一种语言各编写一个简单的测试程序，然后分别用相应的解释器运行，结果发现，所有解释器都通过了测试，每一种解释器都能够稳定地工作或能够方便地与之交互。既然每一种解释器都值得考虑，那么，有哪些因素可能使开发者偏爱其中一种呢？

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脚本语言对比的示例分析”这篇文章的所有内容，感谢各位的阅读！相信大家都有了一定的了解，希望分享的内容对大家有所帮助，如果还想学习更多知识，欢迎关注行业资讯频道！