Rhinos to the Rescue

Java 1.6 saw the introduction of the standardized JSR-223 interface for accessing scripting languages in the javax.script package. The mechanism relies on a principle similar to integrating JDBC drivers. Listing 3 demonstrates the principle based on the nashorn ScriptEngine class developed in the course of the OpenJDK project. The name is a tribute to Mozilla's Rhino [5], the first JavaScript implementation in Java. Nashorn (German for rhinoceros) also implements a JavaScript runtime (ECMAScript Edition 5.1).

01 import javax.script.*;
02 import java.io.*;
03
04 public class ExecScript {
05     public static void main(String[] args) throws Exception {
06         ScriptEngineManager manager = new ScriptEngineManager();
07         ScriptEngine engine = manager.getEngineByName("nashorn");
08         engine.eval(new FileReader(args[0]));
09     }
10 }

Using ScriptEngineManager (line 6), the code generates a ScriptEngine, which comes with a variety of eval() methods that run scripts from strings or files. The whole thing is dynamic; ScriptEngineManager implements an autodiscovery mechanism and serves up the engines. If the application finds the ScriptEngine for Python in the class path, it runs Python scripts without any programming overhead.

Online you will find an admittedly fairly old repository with ScriptEngines for all kinds of scripting languages [6]. A non-JSR-223-compliant variant for Jython itself is also available. Jython provides its interpreter as the org.python.util.PythonInterpreter class, and its exec() method executes the Python code that you pass in.

An Archipelago of Scripting Languages

There is hardly a scripting language that Java cannot integrate or for which a native implementation does not exist. Google finds at least five projects for Lua alone, including Luaj [7]. Along with CPython and Jython, you'll find JRuby [8], a Ruby implementation in Java. In contrast to the stubborn myths about Java's lack of speed, various tests demonstrate that the Java implementation of a scripting language actually beats the original implementation – typically in C/C++ – for speed.

Other languages use the JVM at run time; in other words, the compilers generate Java-compatible bytecode. Prominent examples include Clojure (Lisp) and Groovy. You can find a long list online [9].

Desktop Integration

Desktop integration is a further reason for mixing Java with a third-party language. The technique for doing so is similar to other application scenarios, and again it relies on JNI. For Linux desktops, there are the Java-Gnome [10] and Qt Jambi [11] projects. Because Qt itself is platform-independent, chances are the greatest here that integration with Windows will work.

In all, programming on the desktop turns out to be a borderline case for meaningful Java mixing. The desktop libraries are permanently on the move, and any connector can only play catch up with current events. However, because Java itself has a very good and platform-independent UI library today, the benefits of desktop use are restricted to the uniform look and feel – and this is typically not enough to outweigh the drawbacks.