Having just emerged from a public beta process that began in the spring of 2005, and especially now that Java is an open-source project, developers will find little to be surprised about in Sun's newest Java SE 6, released yesterday. But one sign that even Java is adapting with the times - besides its smaller size, which early adopters are applauding - is its new support for external scripting engines, which adopters might not be aware of.

For the first time, Java is "aware" of the presence of scripting languages, including JavaScript - which recently became part of the Java bundle. With scripting languages like Asynchronous JavaScript (AJAX) rapidly becoming common in the creation of browser-based front ends, Java SE 6's new recognition for scripting engines like JavaScript that follow a standard API to provide scriptable, server-driven functionality.

It could change the architecture of Java-based applications going forward, from nuggets of self-contained programs to distributed systems that use Java for the engine, and JavaScript for the user console. (Sun did not develop JavaScript initially; Netscape did, and it's successor company Mozilla's JavaScript engine that is being bundled with the new Java.)

Early snippets of JavaScript-supporting Java source code reveal a typically simple mechanism behind this otherwise aesthetically asynchronous concept. First, a newly declared variable of class ScriptEngineManager instantiates an instance of Java's new manager function.

From there, another variable is set to point to a handle of the first active script engine it sees in memory. With that handle, JavaScript code (or whatever the native code for the engine may be) is passed a string by way of the eval method; the script engine treats this as though it were being invoked immediately, as through a command line. Java's exception handling mechanism can then catch any errors.

Alternately, the script engine can be set to point to an existing .JS file by declaring a variable of class FileInputStream, with the filename as the sole argument. Some Java developers may have just read the only documentation they'll ever need on the subject - it's literally that simple.

But why do it? Being able to craft an application's front-end functionality in JavaScript by definition means being able to use XHTML for the layout and XML for provisioning to the outside world. Java has historically never had a visually resplendent foundation for user interfaces.

But with JavaScript as a real tool, a Windows developer can craft a front end in XAML that takes full advantage not only of Internet Explorer 7, but also the Windows Foundation Class libraries while retaining a high degree of platform independence. That, and applications' front ends will look a whole lot better.

For those who will be crafting native Java front ends, SE 6 (still known by its loving creators as "Mustang") supports a strengthened windowing foundation class system called Swing. Among other long-desired features, Swing now enables developers to deploy drag-and-drop functionality that's compatible with documents, files, and other objects from outside the realm of Java. Now users will be able to drag items from Windows Explorer into a Java-managed window, and have that window respond using a standard API.

Also in the "At Long Last" category is direct support for Web services, as embodied by the JAX-WS API. While Web services development tools such as Forte and Web Services Developer Pack (WSDP) has been part of Java distributions for several years, what's been missing is a standard means by which Java applications could consume Web services by way of SOAP protocol. For what's called an "endpoint deployment model," clients in a distributed environment are typically thin, relying on server-driven functionality, having clients place multiple requests using an internal HTTP driver.

Until recently, such a driver had not been formalized for Java; and due to security and architectural implications, not all developers had been certain they even wanted one.

With the inclusion of JAX-WS, that argument has been put to rest. The client HTTP driver is there, and developers will have to learn to live with it for the sake of interoperability.

As Java creator James Gosling wrote in an open letter to the Java development community yesterday, "Java technology has been a cornerstone of software development for more than a decade now - the community is ready for the next chapter, and the timing is right...We intend to take steps to help make sure Java technology remains compatible, interoperable, and reliable. And we know the Java community feels the same way."