The Return of Scripting Languages (Java 1.6)

        With the advent of Asynchronous JavaScript and XML (AJAX)-based rich Web applications, scripting languages have made a comeback. This time, the script is meant to run at the client, where scalability generally isn't an issue (each client runs its own browser and hence its own scripts). The result is a very dynamic Web page that includes rich application features with acceptable performance.

Further reasons to use scripting languages in a Web application include dynamic type conversion (automatic conversions from values to strings), access to the operating system environment (as with shell scripts), and the use of specialized Web frameworks for scripting languages. For these reasons, dynamic scripting languages have reemerged on the server as well.

However, this reintroduction of scripting languages has left programmers wanting the following:

  • Access to the rich resources of the Java platform, as well as custom JAR files, from scripting languages
  • Access to scripting languages from the Java platform itself

Java SE 6 satisfies both of these requests with JSR 223 (Scripting for the Java Platform). When you join the features of both the Java language and available scripting languages, you can pick and choose the strengths of both environments to use at the same time. For instance, Java developers can access Perl scripts to perform string operations that are best done with Perl. Additionally, AJAX developers can invoke Java objects directly from script embedded within a Web page to perform complex operations. For example, since database access is far less robust (if not impractical) from JavaScript as compared with Java, you can perform this and other complex operations in Java code and simply invoke the Java code from your page's script.

        Java SE 6 ships with the Mozilla Rhino scripting engine, but you're free to substitute any available scripting engine that complies with JSR 223. This includes implementations of Python and Ruby. The new javax.script APIs provide access to the scripting environments from Java. For instance, the following code iterates through the list of available scripting engines and outputs the language types and the associated engines:

I will show you a simple example that can both access and modify native Java objects.

ScriptEngineManager mgr = new ScriptEngineManager();
ScriptEngine jsEngine = mgr.getEngineByName("JavaScript");
List<String> namesList = new ArrayList<String>();
  namesList.add("java");
  namesList.add("Servlet");
  namesList.add("JSP");
  namesList.add("JSF");
Invocable invocableEngine = (Invocable)jsEngine;
  try {
    jsEngine.eval("function printNames1(namesList) {" +
                  "  var x;" +
                  "  var names = namesList.toArray();" +
                  "  for(x in names) {" +
                  "    println(names[x]);" +
                  "  }" +
                  "}" +
 
                  "function addName(namesList, name) {" +
                  "  namesList.add(name);" +
                  "}");
    invocableEngine.invokeFunction("printNames1", namesList);
    invocableEngine.invokeFunction("addName", namesList, "JavaScript");
  } catch (ScriptException ex) {
    ex.printStackTrace();
  } catch (NoSuchMethodException ex) {
    ex.printStackTrace();
  }
 

You can also create new Java objects in the scripting environment. After importing the necessary Java platform packages, your script can use any native Java class. Instead of printing messages to the console, you could create a Swing message dialog box from your script

try{
    jsEngine.eval("importPackage(javax.swing);" +
        "var optionPane = " +
        "  JOptionPane.showMessageDialog(null, 'Hello, world!');");
}catch (ScriptException ex) {
    ex.printStackTrace();
}

 

 

Syndicate content