Scripting and Java

By Allen Holub

February 15, 2006 —

The “general wisdom” about scripting languages—that systems written in them go together much faster and are much more flexible than compiled languages—is largely unsubstantiated conjecture. I just don’t believe that there’s anything inherent in a scripting language that makes for faster development and greater flexibility. I have noticed that garbage code written in PHP actually works a significant percentage of the time and that garbage code written in Java rarely works at all.

When a Java system is well-written, it’s quite flexible, and incremental changes of the sort championed by the scripting folks are easy to do. Moreover, not everything’s easy in a script. Take your average PHP system, where the HTML is embedded right in the PHP code that’s also implementing business logic. Simple look-and-feel changes, which would be trivial in a JSP-with-custom-tags system, are painful at best.

On the other hand, scripting languages do have their uses. For example, if you’re using AJAX heavily on a site that does little more than expose a database to the Web, then a scripting language is a perfectly good choice for supplying the glue that connects the AJAX control to the database. More complex sites require more complex structure, however.

Put another way, scripting languages are great for some parts of a system but not others. Hybrid systems—part Java, part PHP, part Ruby or Python—are becoming commonplace for good reason. If done properly, a hybrid architecture can solve complex problems better than a system written entirely in any one language. This structure is really just the hoary notion of a small language. Use a language that’s appropriate for the job at hand.

On the building-hybrid-systems front, JSR 223, Scripting for the Java Platform, is of particular interest. This JSR is slated for inclusion in the Mustang release and provides a means of interfacing Java programs to arbitrary scripting languages. A reference implementation is available, along with the full specification, at jcp.org and connects Java to PHP, JavaScript and Groovy.

The expert group has done an exemplary job. Not only is the specification itself well-written, but what the spec does seems well-thought-out and honestly useful. Three scenarios are handled: calling into Java code from the scripting language, executing scripts from Java, and executing scripts from servlets.

The spec can’t really dictate how every scripting language should make Java calls, since every language has its own syntax, but it does make some suggestions. The basic idea is to use a wrapping strategy around objects that represent the Java equivalents. For example, a PHP program might do the following:

$javadate = new Java(“java.util.Date”); $date = $javadate->toString();

Note how the system takes care of type conversions for you. (I haven’t shown the arguments in this example, but these will be converted properly.) A server-side script could even do something complicated like get the Java Thread object that’s processing the request and putting it to sleep for a few seconds, or communicating over a socket opened by the Java side of the program.

Moving in the other direction, the Java APIs center on the notion of a “scripting engine” that executes the script. You can instantiate engines for several languages simultaneously. The notions of namespaces are supported, and you can inject Java variables into (and remove them from) the engine to make them available to the script, which could access them as global variables, for example. You pass a string containing a script to the engine for processing (or pass it a reader) and the engine executes the script. (You can, of course, use Runtime.exec() to execute a script in another process simply by running the PHP interpreter, for example, but you’ve always been able to do that.) Perhaps more interestingly, you can pass a script into an Engine, then call individual subroutines in the script and get back the return value.

The Servlet APIs differ from the other Java-side APIs in that they give the script access to the session, request and response objects. That is, you can do part of your processing in a servlet or in JSP, and you can delegate other processing to a PHP or Ruby script. All three systems will be reading from the same request and writing to the same response, and they can all share information in the session.

To my mind, the sort of interlanguage interoperability that’s possible with JSR 223 is wonderful. Java is a great language, but there’s no single language that’s best at everything. This project gives us the ability to write programs that let us use the most appropriate tool for the task at hand.

Allen Holub is an architect, consultant and instructor in C/C++, Java and OO Design. Reach him at www.holub.com.

Share this link: http://www.sdtimes.com/link/29129

Apache Pivot brings Java into RIA world Open-source Java-based RIA framework brings speed of other RIA development environments to a pure Java world

Java 2009: The language moves to the platform A pair of major acquisitions has potentially diminished Sun's sphere of influence over the language

An opening for closures in Java Sun's Mark Reinhold says he has the answer for Java scaling difficulties, and it involves adding closures to Java

Add comment

Name*
Email*
Country

Comment
Preview

News on Monday
more>>
SharePoint Tech Report
more>>

Download Current Issue
ISSUE 3/15/2010 PDF

Need Back Issues?
DOWNLOAD HERE

Receive the print Edition?

Google Code turns 5
Google Code Turns 5, and adds a Paxos Algorithm to make the system more stable and reliable.
03/17/2010 11:16 AM EST

Test your Visual Studio 2010 know-how
Microsoft is offering free beta certification exams for Visual Studio 2010.
03/17/2010 11:08 AM EST

Microsoft lifts the hood on IE9
Microsoft is previewing IE9.
03/16/2010 01:10 PM EST