ince I wrote a DevX article on the first beta release of Java Standard Edition (SE) version 6 in February of this year, two new early-access versions have been released. This article discusses the first Java SE 6 release candidate, a feature-complete, almost fully tested implementation of the newest version of desktop Java. While the article in February focused on many GUI features (and declared Java SE 6 a desktop winner), this one focuses on some other new features and improvements, namely scripting and the compiler API.

Java Supplants Scripting
In the early days of the enterprise Java standard (what was called J2EE and is now called Java EE), many Web site designers employed server-side scripting to implement functionality. Available tools and software made it easy to develop and deploy this type of business logic, but they had two huge drawbacks: poor performance and little debugging assistance. Server-side scripts, such as those implemented as JavaScript, are not compiled; they're interpreted as they execute. This leads to poor performance and little to no scalability.

The emergence of the Java Servlet specification and, subsequently, JavaServer Pages (JSP) put an end to all of that. 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.

The Return of Scripting Languages
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. (For a list of JSR 223-compliant script engines, click here.) 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:

import java.util.*;
import javax.script.*;

public class Main
{
    public static void main(String[] args)
    {
        try {
            ScriptEngineManager mgr = new ScriptEngineManager();
            List<ScriptEngineFactory> factories = mgr.getEngineFactories();
            System.out.println("Available script engines:");
            for ( int i = 0; i < factories.size(); i++ )
            {
                ScriptEngineFactory factory = factories.get(i);
                String engine = factory.getEngineName();
                String language = factory.getLanguageName();

                System.out.println("-------------------------------------------");
                System.out.println("Language: " + language );
                System.out.println("Engine: " + engine);
                System.out.println("-------------------------------------------");
            }
        }
        catch ( Exception e ) {
            e.printStackTrace();
        }
    }
    
}

JSR 223-compliant scripting engines must implement the javax.script.ScriptEngine interface and be packaged in JAR files with a META-INF/services/javax.script.ScriptEngineFactory text resource. Once you deploy a compliant scripting engine JAR file into your Java environment or with your application, you can access this engine from your Java code. To do this, simply include the engine's JAR file within your application's classpath.

Let's examine the Rhino JavaScript engine's Java scripting features with some simple examples.