Choose the appropriate Java scripting language

Script selects the appropriate Java scripting language
-If you're considering integrating a script interpreter in a Java application, it's most difficult to decide to use the

Absrtact: The scripting language has proven its value to Java developers. It enables the customer to realize the extension of the application function and personalization of the interface, thus the value of the program can be improved. In addition, they can significantly simplify the design tasks of program developers by implementing dynamic definition, loading, and evaluation. For developers, the task of integrating one or more scripting languages is simple, and choosing from an increasingly long list of alternatives is really difficult. This article describes some of the problems associated with scripting language support in Java applications and compares groovy, Judoscript, pnuts, JRuby, Jacl, Jython, Rhino, and BeanShell from different perspectives to help readers make the right decisions.

Three years ago, I wrote in Javaworld called "javascripting language, which is right for you?" "The article. When I collect the interpreter and compare it, I try to choose those that seem to meet demanding business needs. Ideally, I hope that the interpreter will be able to easily extend the user interface of the application and have readable scripting code, high reliability, fast, good support and documentation, and complete. At that time, I restricted the list to Jacl,jython,rhion and BeanShell.

Many changes have taken place in the past three years. The option is no longer a few, whether dynamically developed or directly selected, there are more than one dozen scripting languages available. The list of reliable choices is more than three years ago, and now includes groovy, Judoscript, Pnuts and BeanShell. We can also consider other interpreters that are no longer in this list, but this list is already sufficient for the developer's own needs.

I'm going to standardize all the interpreters and see how Jacl, Jython, rhion and BeanShell have improved in 2002 years, and see what Groovy, Judoscript, JRuby and pnuts compare to them. I think it's interesting to see what's unique about different scripting languages and what particular strengths and weaknesses are.

Business risk

In my previous article, I described some of the best known examples of good scripting interpreters and explained the risks you might encounter when combining the script interpreter. In this article, I've simplified the content to a few points and improved it based on my experience after writing those articles. The advantages of the Java Script interpreter are beyond doubt. scripting language encoding is simpler than using Java; Footstep language drives the application logic and user interface of a program (drive/driven?) and extensions are possible; Scripting code can run against class interfaces in Java applications, which is a very powerful feature. This makes it easy to write test drivers for programs (write test drivers against your program), which is faster than coding and compiling unit tests for Java classes. In addition, if users spend time using scripts to extend your application, they invest in your tools, which makes you a more powerful tool in the competition.

However, when integrating the Jiava script interpreter in an application, you must face certain risks. The two main risks are that the interpreter may be orphaned, or that when you load the product, you may find the interpreter's fatal flaw. Most interpreters are dynamically maintained and updated through the open source model, in which case you can ask the expert who is studying the problem you find to help, patch the interpreter, or include the bug-fix you need in future releases (bug fixes?). ）。 It's a safe bet, but it's not guaranteed enough. If you are serious about using a particular interpreter, look at its development site, see the evolution of its code, see the gossip board, and the user's questions are answered. This will help you understand the actual code support.

Another measure of self-protection is to fully test what interpreter you are going to use for the script. Some interpreters include a unit test set at the time of publication. When testing the integrated interpreter in your application, these unit tests can be part of your larger test set. When testing the integration between the interpreter and the application, you can get out of your work (you have your work) because the script interpreter is flexible enough to expose enough functionality to the developer. You put time into quality assurance early on, not when applications have become products, but when users need urgent bug fixes.

New List of competitors

If you are looking for a script interpreter, you have a lot of options. Some interpreters support already existing languages, such as Ruby, Python, JavaScript, Java, and Tcl. Other interpreters, such as judoscript, groovy, and Pnuts, have chosen their own Java-like language syntax. The biggest choice to make in comparison with different interpreters is that the syntax of the scripting language works well for your application. Technological choices such as the effects of individual preferences may be hotly debated in different team of developers. Perhaps this article will help to resolve some of the arguments.

I collected a comparison of the eight different script interpreters that were recently released. Both the interpreter and its version are listed in the following table. If you are unfamiliar with these interpreters, I also give an overview of each of the interpreter features and development activities (a thumbnail sketch).

Scripting languages

Version number

Brief description

Jacl

1.3.1

The Java implementation of the TCL interpreter. If you want to use a toolkit in a script to create a user interface class, look at the class set of the parcel (wrap) Java Swing tool in the swank project. Jacl has been around for a long time and is still improving.

Jython

2.1

The Java implementation of the Python interpreter. One of the problems I've noticed is that I haven't seen a new version of this interpreter for a long time. But on Jython's website, there are plans to change the status quo, and there are funds to support it.

Rhino

1.6.1

Java implementation of the JavaScript interpreter. It also supports the compilation of scripts into class files. Its latest version was released a few months ago, and XML support was added.

Jruby

0.8

The Java implementation of the Ruby interpreter. It is developing and its beta 0.8 is doing well.

BeanShell

2.0 Beta 2

It is a Java source file interpreter that is constantly evolving and adding new features. The 2.0 version provides complete general Java source interpretation support.

Groovy

1.0 Beta 9

Groovy is formed by adding Python and Ruby features to Java-like syntax, with many exciting features. You can compile scripts directly into class files, and for different Ides and many groovy plug-ins to choose from, the JSR Committee is developing groovy specifications.

Judoscript

0.9

It has the same programming syntax as JavaScript, and it's easier to learn and use. One of its clear goals is mentioned in its FAQ: "Support for object-level, OS-level, and application-level scripts." The 0.9 version of my test runs well.

Pnuts

1.1 Beta 2

Pnuts has the same programming syntax as Java and keeps it up to date. It can compile the script directly into a Java class file.

First Indicator: Performance

To test the first indicator in the future, I wrote the equivalent scripting code for each interpreter, allowing them to complete a simple set of tasks and record the time they spent executing the script. My test script focuses on basic operations such as loops, integer comparisons, and large one-dimensional, two-dimensional array allocations and initialization. Test scripts for each interpreter and Java programs that run them can be downloaded in the original source section.

The most useful information in benchmark tests is the apples-to-apples comparison of the interpreter's simple task speed. If you focus on throughput, the number of benchmarks will be very important. For each scripting language, I try to write the test code for my acquaintance. The test uses Java1.4.2 to run on the Toshiba TECRA8100 notebook, CPU for Piii700mhz, memory 256MB. The default heap size is used when starting the JVM. To show you how fast or how slow the interpreter is, I wrote the Java code for the test case and ran it on the java1.4.2. Test sets include:

Count of 1 to 1,000,000

1,000,000 Times integer Equality comparison

To allocate and initialize an array of 100,000 elements

Allocates and initializes a two-dimensional array of 500*500

Is there any improvement in 2002 years?

Before we tell you which interpreter is the fastest, let's take a look at Figure 1, which lists the results of many time-consuming tasks: 1 million times integer equality comparisons. For the 4 script interpreters described in the 2002 article, I gave you the time required to run on JAVA1.3.1JVM and Java1.4.2. Interestingly enough, the same version of the script interpreter was used to test the Jython, which showed a 25% increase in speed on the new JVM. Plus I used exactly the same hardware as the previous test, so it's certain that JVM1.4.2 reduces the time it takes to run the underlying tests. Now look at what happened to Rhino,beanshell and Jacl: The new version of Rhino on the 1.4.2 JVM is 76% happier than the older versions that run on the 1.3.1 JVM. As you can see, performance has improved a lot.



Total time of four tasks

Since the interpreter is very similar in speed (at least for my benchmark test), I calculated the total time that the interpreter had spent on the four benchmark tests and presented it in Figure 2.



The changeable sign

For these simple tests, rhino,pnuts and Jytho are always the fastest, immediately followed by groovy, then Judoscript, and then others. These performance parameters are useful to you, depending on what you want the scripting language to do. If your script function contains a large number of iterations, and the user waits for the result, you need to focus on the fastest interpreter, or you should consider the algorithm for implementing high-performance requirements in Java, rather than scripting code. If your script only requires very little repetition, the speed difference between these interpreters is not so important, and fast hardware can make the problem different.

It is also important to point out that even the fastest interpreter, the time it takes to complete the test above, is about 40 times times the time it takes for Java code to function. If speed is your main problem, you must be aware that the most significant thing is to use Java instead of scripting code to implement critical algorithms.

Some script interpreters support scripting code that compiles directly into bytecode. I was curious about how much performance difference this would make, so I did another test. I compiled the benchmark script into bytecode using the Rhino script interpreter, and I ran the entire benchmark set 10 times, using script and script-generated bytecode respectively. Surprisingly, the script code compiles into bytecode and then runs only 10% of the time compared to running a script directly. My initial task, the JVM's magic spell took up most of the time to run the test set, but further checks found that the JVM curse itself accounted for only 20% of the total running time of the test set. The simple scripting code that compiles into bytecode seems to have a positive meaning, but it's not necessarily a silver bullet that significantly improves performance. Maybe in a longer or more computing center script, you'll see different results.

Second Standard: Integration difficulty

Third Standard: License

English Original:

Http://www.javaworld.com/javaworld/jw-03-2005/jw-0314-scripting.html