While scripting Java code has been possible for several generations of JDK releases—see the Artima interview with Patrick Niemeyer, Scripting Java: The BeanShell JSR—Java classes did not play well with scripting languages. JSR 223, Scripting for the Java Platform, introduced the ability for Java code to invoke scripts through scripting engines. JDK 6 provides an implementation of JSR 223, bringing full-fledged scripting to Java.

In a recent DevX article, Java SE 6's New Scripting and Compiling Goodies, Eric Bruno introduces some of the new scripting capabilities, including ScriptPad a sample application shipped with the JDK that allows execution of any JavaScript code.

Bruno notes that scripting moved from server to the client in recent years:

The emergence of the Java Servlet specification and, subsequently, JavaServer Pages (JSP) put an end to [server-side scripting]. Because these server-side technologies were based on pure Java, tools emerged to help you debug the code. Additionally, since the Java code could be compiled (thanks to the HotSpot compiler), performance and scalability were excellent. This marked the end of mainstream server-side scripting...

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)...

With JSR 223 scripting, either client- or server-side code can take advantage of scripting languages:

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... AJAX developers can invoke Java objects directly from script embedded within a Web page to perform complex operations...

Bruno then introduces ScriptPad, a demo application that ships with the JDK to demonstrate executing JavaScript inside a Java application:

ScriptPad, is a 99 percent JavaScript application that loads and executes other scripts, all through the Java scripting API. It uses Java to load the Rhino JavaScript engine and execute the five script files that are built into ScriptPad. Included in the sample/scripting/scriptpad folder within your Java SE 6 installation root folder, ScriptPad comes complete with a NetBeans 5.5 project file, which you can use to easily build and execute it.

Bruno also shows code snippets to illustrate how a few lines of Java code can load a script engine, and then execute a script from a file:

ScriptEngineManager m = new ScriptEngineManager();
ScriptEngine engine = m.getEngineByName("javascript");
if (engine != null)    {
    InputStream is = 
         this.getClass().getResourceAsStream("browse.js");
    Reader reader = new InputStreamReader(is);
    engine.eval(reader);
    Invocable invocableEngine = (Invocable)engine;
    invocableEngine.invokeFunction("browse");
}

What parts of an enterprise application would you consider most suitable for scripting? To what extent do you think delegating functionality to external scripts make an application's behavior harder to test?