A scripting language is a language that avoids the usual edit/compile/link/run cycle by interpreting the program text at runtime. Scripting languages have a number of advantages:
- Rapid turnaround, encouraging experimentation
- Changing the behavior of a running program
- Enabling customization by program users
On the other hand, most scripting languages lack features that are beneficial for programming complex applications, such as strong typing, encapsulation, and modularity.
It is therefore tempting to combine the advantages of scripting and traditional languages. The scripting API lets you do just that for the Java platform. It enables you to invoke scripts written in JavaScript, Groovy, Ruby, and even exotic languages such as Scheme and Haskell, from a Java program. For example, the Renjin project (www.renjin.org) provides a Java implementation of the R programming language, which is commonly used for statistical programming, together with an “engine” of the scripting API.
In the following sections, we’ll show you how to select an engine for a particular language, how to execute scripts, and how to make use of advanced features that some scripting engines offer.
1. Getting a Scripting Engine
A scripting engine is a library that can execute scripts in a particular language. When the virtual machine starts, it discovers the available scripting engines. To enumerate them, construct a ScriptEngineManager and invoke the getEngineFactories method. You can ask each engine factory for the supported engine names, MIME types, and file extensions. Table 8.1 shows typical values.
Usually, you know which engine you need, and you can simply request it by name, MIME type, or extension. For example:
ScriptEngine engine = manager.getEngineByName(“nashorn”);
Java 8 introduced Nashorn, a JavaScript interpreter developed by Oracle. You can add more languages by providing the necessary JAR files on the class path.
2. Script Evaluation and Bindings
Once you have an engine, you can call a script simply by invoking
Object result = engine.eval(scriptString);
If the script is stored in a file, open a Reader and call
Object result = engine.eval(reader);
You can invoke multiple scripts on the same engine. If one script defines variables, functions, or classes, most scripting engines retain the definitions for later use. For example,
engine.eval(“n = 1728”);
Object result = engine.eval(“n + 1”);
will return 1729.
You will often want to add variable bindings to the engine. A binding consists of a name and an associated Java object. For example, consider these statements:
engine.put(“k”, 1728);
Object result = engine.eval(“k + 1”);
The script code reads the definition of k from the bindings in the “engine scope.” This is particularly important because most scripting languages can access Java objects, often with a syntax that is simpler than the Java syntax. For example,
engine.put(“b”, new JButton());
engine.eval(“b.text = ‘Ok'”);
Conversely, you can retrieve variables that were bound by scripting statements:
engine.eval(“n = 1728”);
Object result = engine.get(“n”);
In addition to the engine scope, there is also a global scope. Any bindings that you add to the ScriptEngineManager are visible to all engines.
Instead of adding bindings to the engine or global scope, you can collect them in an object of type Bindings and pass it to the eval method:
Bindings scope = engine.createBindings();
scope.put(“b”, new JButton());
engine.eval(scriptString, scope);
3. Redirecting Input and Output
You can redirect the standard input and output of a script by calling the setReader and setWriter methods of the script context. For example,
var writer = new StringWriter();
engine.getContext().setWriter(new PrintWriter(writer, true));
Any output written with the JavaScript print or println functions is sent to writer.
The setReader and setWriter methods only affect the scripting engine’s standard input and output sources. For example, if you execute the JavaScript code
println(“Hello”);
java.lang.System.out.println(“World”);
only the first output is redirected.
The Nashorn engine does not have the notion of a standard input source. Calling setReader has no effect.
4. Calling Scripting Functions and Methods
With many script engines, you can invoke a function in the scripting language without having to evaluate the actual script code. This is useful if you allow users to implement a service in a scripting language of their choice.
The script engines that offer this functionality implement the Invocable interface. In particular, the Nashorn engine implements Invocable.
To call a function, call the invokeFunction method with the function name, followed by the function parameters:
// Define greet function in JavaScript
engine.evat(“function greet(how, whom) { return how + ‘ + whom + ‘!’ }”);
// Cat! the function with arguments “Hello”, “World”
result = ((Invocable) engine).invokeFunction(“greet”, “Hello”, “World”);
If the scripting language is object-oriented, call invokeMethod:
// Define Greeter class in JavaScript
engine.eval(“function Greeter(how) { this.how = how }”);
engine.eval(“Greeter.prototype.welcome = “
+ ” function(whom) { return this.how + ‘, ‘ + whom + ‘!’ }”);
// Construct an instance
Object yo = engine.eval(“new Greeter(‘Yo’)”);
// Call the welcome method on the instance
result = ((Invocable) engine).invokeMethod(yo, “welcome”, “World”);
You can go a step further and ask the scripting engine to implement a Java interface. Then you can call scripting functions and methods with the Java method call syntax.
The details depend on the scripting engine, but typically you need to supply a function for each method of the interface. For example, consider a Java interface
public interface Greeter
{
String welcome(String whom);
}
If you define a global function with the same name in Nashorn, you can call it through this interface:
// Define welcome function in JavaScript
engine.evat(“function welcome(whom) { return ‘Hello, ‘ + whom + ‘!’ }”);
// Get a Java object and call a Java method
Greeter g = ((Invocable) engine).getInterface(Greeter.class);
result = g.welcome(“World”);
In an object-oriented scripting language, you can access a script class through a matching Java interface. For example, here is how to call an object of the JavaScript Greeter class with Java syntax:
Greeter g = ((Invocable) engine).getInterface(yo, Greeter.class);
result = g.welcome(“World”);
In summary, the Invocable interface is useful if you want to call scripting code from Java without worrying about the scripting language syntax.
5. Compiling a Script
Some scripting engines can compile scripting code into an intermediate form for efficient execution. Those engines implement the Compilable interface. The following example shows how to compile and evaluate code contained in a script file:
var reader = new FileReader(“myscript.js”);
CompiledScript script = null; if (engine implements Compilable)
script = ((Compilable) engine).compile(reader);
Once the script is compiled, you can execute it. The following code executes the compiled script if compilation was successful, or the original script if the engine didn’t support compilation:
if (script != nut!)
script.evat();
else
engine.evat(reader);
Of course, it only makes sense to compile a script if you need to execute it repeatedly.
6. An Example: Scripting GUI Events
To illustrate the scripting API, we will write a sample program that allows users to specify event handlers in a scripting language of their choice.
Have a look at the program in Listing 8.1 that adds scripting to an arbitrary frame class. By default it reads the ButtonFrame class in Listing 8.2, which is similar to the event handling demo in Volume I, with two differences:
- Each component has its name property set.
- There are no event handlers.
The event handlers are defined in a property file. Each property definition has the form
componentName .eventName = scriptCode
For example, if you choose to use JavaScript, supply the event handlers in a file js.properties, like this:
yellowButton.action=panel.background = java.awt.Color.YELLOW
blueButton.action=panel.background = java.awt.Color.BLUE
redButton.action=panel.background = java.awt.Color.RED
The companion code also has files for Groovy and R.
The program starts by loading an engine for the language specified on the command line. If no language is specified, we use JavaScript.
We then process a script init.language if it is present. This is useful for the R and Scheme languages, which need some initializations that we did not want to include in every event handler script.
Next, we recursively traverse all child components and add the bindings (name, object) into a map of components. Then we add the bindings to the engine.
Next, we read the file language.properties. For each property, we synthesize an event handler proxy that causes the script code to be executed. The details are a bit technical. You might want to read the section on proxies in Volume I, Chapter 6, if you want to follow the implementation in detail. The essential part, however, is that each event handler calls
engine.eval(scriptCode);
Let us look at the yellowButton in more detail. When the line
yellowButton.action=panel.background = java.awt.Color.YELLOW
is processed, we find the JButton component with the name “yellowButton”. We then attach an ActionListener with an actionPerformed method that executes the script
panel.background = java.awt.Color.YELLOW
if the scripting is done with Nashorn.
The engine contains a binding that binds the name “panel” to the JPanel object. When the event occurs, the setBackground method of the panel is executed, and the color changes.
You can run this program with the JavaScript event handlers simply by executing
java ScriptTest
For the Groovy handlers, use
java -classpath .:groovy/lib/\* ScriptTest groovy
Here, groovy is the directory into which you installed Groovy.
For the Renjin implementation of R, include the JAR files for Renjin Studio and the Renjin script engine on the classpath. Both are available at www.renjin.org /downloads.htmL
This application demonstrates how to use scripting for Java GUI programming. One could go a step further and describe the GUI with an XML file, as you have seen in Chapter 3. Then our program would become an interpreter for GUIs that have their visual presentation defined in XML and behavior defined in a scripting language. Note the similarity to a dynamic HTML page or a dynamic server-side scripting environment.
Source: Horstmann Cay S. (2019), Core Java. Volume II – Advanced Features, Pearson; 11th edition.