Scripting in and around Java

Wednesday Jul 19th 2000 by Staff

We look at an array of new scripting languages built to take advantage of the Java virtual machine, which can greatly speed your development efforts.

"Just because the Java API, or any other API written for Java has documentation, doesn't mean that it's always obvious how to interact with it properly. "
Part one of a two-part article
See: Two Java Scripting Languages Close-up

When faced with a new engineering project or task, one of the first questions to cross a developer's mind is often "What language am I going to write this in?" Sometimes Java seems like overkill; we'd like to throw together something quick and dirty, and it might be nice to do interactive development. Typically in such situations, developers prefer Perl, Python, or even Tcl. However, there is a large array of new, neat scripting languages built to take advantage of the Java virtual machine that might be able to better serve your needs than one of those old workhorses. In this article, we're going to look at a few of the more interesting Java scripting languages currently available.

What advantages are there to a language targeting the Java virtual machine? There are many advantages to the person designing the language. Most immediate is portability; the new language has instant access to all platforms for which there is a Java virtual machine. One of the biggest pluses that you'll see in many of these languages is the ability to interoperate easily with Java. If you're used to the depth and breadth of features provided by Java APIs, this benefit may be worth pursuing.

Of course, most of these languages are somewhat off the beaten path, which is a place some developers don't want to go, and rightly so. Braving a language with a small user community that might disappear at any time is not for the faint at heart, no matter how cool the language is. For example, a very cool Java-based scripting language formerly called WebL is currently embroiled in legal battles causing it to disappear from its Web site. Not all Java-based languages are such big risks, though. For example, JPython enjoys a reasonably sized user base and has strong support from the Python community. People get paid full-time to work on it, and that probably won't change.

How about JavaScript? It turns out that JavaScript has nothing at all to do with Java. JavaScript was originally a language by Netscape called LiveScript. When Java first came out, Netscape made a deal with Sun to change the name to JavaScript. The whole goal was to take advantage of the Java hype. Other than the name, JavaScript has nothing to do with Java, beyond the fact that they both can work in a Web browser. JavaScript doesn't use the Java Virtual Machine, or anything.

(Ironically, Sun originally planned to deploy John Ousterhout's Tcl as the first scripting language for Java.)

Implementation of Other Scripting Languages in Java

Working from the description of scripting languages given earlier, all that's needed to get up and running a script language is a text editor to write with, and an interpreter to read the script. The most difficult part is obtaining an interpreter for the platform on which the script is to run. Well, there is nothing that says that Java cannot be that platform.

Sure enough, there are interpreters written in Java for some of the more popular and widely used scripting languages (Perl being the most notable exception). These interpreters usually also allow the scripts access to the Java API as well as the expected functionality of the language itself.



Jacl is an interpreter for Tcl written in 100% Pure Java. Tcl scripts run on the Jacl interpreter can interact with Java's reflection API using the java tcl package. Interacting with the Java API is done through a Tcl extension called Tcl Blend, which comes with Jacl. More information and Jacl downloads can be found at Scriptics.


JPython brings the Python scripting language to the Java VM. JPython and Python are slightly different languages. They are mostly the same, but there are a handful of mostly unimportant differences. The biggest difference is that modules that are not part of the library core are drastically different in each language. JPython lacks many of Python's extension modules, but it gives access to the entire Java standard library. Interoperability between Java code and JPython is straightforward.

Scripting Java

"Java-based scripting languages have a lot to offer, despite their relative immaturity."

Just because the Java API, or any other API written for Java has documentation, doesn't mean that it's always obvious how to interact with it properly. When faced with a new Java API, some time is usually spent writing and compiling a class file that contains a single routine,

, that repeatedly calls into the API in question, and System.out. This trial-and-error experiment with Java APIs is slow and tedious. Wouldn't it be great to be able to do these kinds of simple kick-the-tires tests without involving the compiler?

There are a couple of different implementations of systems that script Java. The common element they share is the ability to execute Java statements without having to compile source code to class files.



BeanShell is a source interpreter that allows scripting of Java objects. BeanShell, or bsh, can be run in a few different ways. First, one can write bsh scripts in a text editor, and then submit them to the bsh interpreter for execution. BeanShell can also be run in interactive mode, similar to a command shell like bash, csh, or the Windows command prompt.

In addition to a GUI desktop mode that provides multiple bsh windows, a text editor, and a class browser, BeanShell also contains a server mode. The server mode allows an applet to connect to a running instance of bsh on the machine from which the applet was served. The applet can then send bsh scripts and commands back to the running instance on the server machine. Also when running in server mode, a remote client can telnet to the port that bsh listens on to find a bsh command prompt.


Originally built as a quick method for testing, Pnuts originated in Sun Japan. Pnuts provides more built-in functions that access the Java APIs than BeanShell, but lacks a GUI desktop environment. However, Pnuts provides some translation and compilation functions that BeanShell does not. For example, scripts written in Pnuts can be translated into Java source code, which can then be compiled by javac. The output of the translation will include a

function so that the result can be compiled and run. Pnuts scripts and expressions can also be "compiled" to improve performance. The result of a Pnuts compilation is a serialized class that can later be stored in a jar file for distribution to another Pnuts user, for example. Compilation is also said to improve performance.

Pnuts has a server mode similar to that in BeanShell discussed above. Whereas in BeanShell, the server mode is used to facilitate remove commands, the Pnuts Personal Server is used as a performance enhancement. After starting a server, a lightweight client (psh) is used to send commands to the server. Interacting with Pnuts in this simple client/server mode saves the overhead of having to start the Pnuts runtime environment when every script is run.

On Windows, Pnuts provides an OLE/COM adapter that can allow a script to access other applications such as those in the Office suite, similar to how Visual Basic can interact with other applications. Also on Windows, Pnuts provides functions that allow scripts to emulate VBscript.

Original Scripting Languages for Java

Since no scripting language is to everyone's liking, there are interpreters for languages written specifically for Java. These languages could have interpreters written in a native language like C, but their designers either take advantage of the Java APIs and provide mechanisms for accessing them, or they didn't want to write a version of the interpreter for every combination of hardware and operating system known to man. Since Java VMs are available on most platforms these days, writing an interpreter in Java gives these scripting languages access to a fairly large user base to draw from. Anyone with a Java VM and a knack for picking up languages can quickly and easily become fluent in a new language. Meanwhile the language developer can focus on more important things than handling requests for porting the interpreter to a different OS/hardware combination.


WebL (now Compaq's Web Language)

WebL (which has now had a name change) is a scripting language tailored to operating on HTML documents fetched from remote sites. WebL contains primitives that facilitate downloading data through HTTP and FTP, and more primitives that allow operating on HTML data retrieved over the network. Through these two sets of advanced primitives, in addition to WebL's other fairly standard primitives such as Sets, Functions, Methods, Objects, and Lists, one can script fairly complex Web applications. WebL also allows the creation of a Function or Method primitive in "native" Java, meaning that any new Java API (JDBC, JavaMail, etc.) can be connected to WebL through this "native" extension mechanism.

As this article was going to press, the WebL name was changed to Compaq's Web Language, after some legal wrangling over the "WebL" name itself.


Scripting languages can be good for many things; from rapid-prototyping, to experimentation, to full-blown standalone applications. However, not every scripting language is suitable for every task, and sometimes no scripting language is suitable for the task (such as systems programming). Java-based scripting languages have a lot to offer, despite their relative immaturity. In particular, you can often win out in the ease of implementation arena, while being able to interoperate with your Java applications.

In our next article: Two Java Scripting Languages Close-up, we'll go into more detail about two of the above languages we discussed above, which will include more in-depth discussion, as well as some example scripts.

About the Authors

Tom O'Connor is an application engineer at

John Viega is a senior research associate and consultant at Reliable Software Technologies, as well as an Adjunct Professor of Computer Science at the Virginia Polytechnic Institute. He is the author of Mailman, the GNU Mailing list manager, and its4, a tool for finding security vulnerabilities in C and C++ code.

Mobile Site | Full Site
Copyright 2017 © QuinStreet Inc. All Rights Reserved