Optimize with a SATA RAID Storage Solution
Range of capacities as low as $1250 per TB. Ideal if you currently rely on servers/disks/JBODs
Three years ago, I wrote an article for JavaWorld called "Java Scripting Languages: Which Is Right for You?" When I collected the interpreters to compare, I tried to choose ones that seemed a good fit for a demanding commercial application. Ideally, I wanted an interpreter that would ease the extension of the application's user interface, have readable scripting code, be reliable, fast, well-supported, well-documented, and complete. At that time, I narrowed the list down to Jacl, Jython, Rhino, and BeanShell.
A lot has changed over the last three years. Instead of a handful of choices, there are now more than a dozen scripting languages either under active development or already available for use. The list of solid choices is bigger than it was three years ago and now includes Groovy, JudoScript, Pnuts, and JRuby, in addition to Jacl, Jython, Rhino, and BeanShell. We could consider other scripting interpreters beyond this group, but this list is large enough for developers to find what they're looking for.
I wanted to benchmark all of these interpreters to see if the performance for Jacl, Jython, Rhino, and BeanShell had improved since 2002, and to find out how Groovy, JudoScript, JRuby, and Pnuts compare with them. I thought it might be interesting to see what's unique about the different scripting interpreters and if any have particular strengths or weaknesses.
In my previous article, I called out some of the well-known benefits of scripting interpreter integration and described the risks you take when integrating with one. Here, I boil that information down to the most important points and update the information based on my experience since writing the last article.
The benefits of Java scripting interpreters are substantial. For one thing, scripting languages can be simpler to code in than Java. Scripts also make it possible to drive and extend your program's application logic and user interface. They can be run directly against your Java application's class interfaces, which is very powerful. This can make it easier to write test drivers against your program much more quickly than if you had to code and compile unit tests against the Java classes themselves. Also, if users take the time to extend your application by writing scripts for it, they're making an investment in your tool—and that can give your application an edge against the competition.
You do open yourself up to a certain amount of risk by integrating a Java scripting interpreter into your application, though. The two biggest risks are that the interpreter will be orphaned or that you will discover a fatal flaw in the interpreter after you ship a product with it.
Most of the interpreters are actively maintained and updated through an open source model, and, in those cases, you can probably rely on experts for help on working around problems you find, patching the interpreter, or getting the bug-fix you need included in a future release. That's a safe bet, but not a guarantee. If you are seriously considering using a specific interpreter, take a look at the activity on the development site to get a feel for how the code is evolving and look at the message boards to see if user questions are getting answered. That will give you a feel for how well supported the code really is.
|Forum migration complete By Athen|
|Forum migration update By Athen|
|Groovy By Anonymous|
|use scripting language in Pestore By Mario Ne|
|Why DynamicJava is not in the list? By Anonymous|
|another criterion should be error reporting By lorenzo|
|Choosing a Java scripting language By JavaWorld|