Advertisement

Java scripting standards

Frank Sommers: With JSR 274 now accepted as a JSR, the JCP seems to have three different scripting-related JSRs: "Scripting for the Java Platform" (JSR 223), "The Groovy Programming Language" (JSR 241), and now BeanShell (JSR 274). Why have three separate scripting-related JSRs, and what is the relationship between those efforts?

Pat Niemeyer: "Scripting for the Java Platform" defines the new javax.script API for working with scripting languages from Java[3]. That API will ship with Mustang (Java 6.0). I was a member of that expert group as well. Developers who have used the IBM/Apache Bean Scripting Framework (BSF)[4] are already familiar with what this API offers. The javax.script API insulates you from the mechanics of looking up a scripting engine, figuring out how to bind variable values to a script, and execute a script.

The javax.script API was crafted to work with a broad range of scripting languages, and has some powerful features, such as a truly pluggable environment. If I want to script an Ant task via a new scripting language I just invented, for instance, all I have to do is drop in the JAR file for my language, and I'm done. Ant doesn't care what language I use for the script, assuming the Ant task understands the javax.script API.

The scripts themselves are in different languages, and are not interchangeable. However, javax.script goes a long way towards allowing an application to be scriptable and extensible via whatever scripting language a user wants to use. For instance, you can expose variables of your application to any script via a simple Map interface, and any script will see those variables just as if those variables were declared inside the script.

Next came Groovy[5] and BeanShell. I'm ashamed to say that I don't know very much about Groovy. However, I like what I've seen, and I hope that they are very successful. That said, when I saw the Groovy presentation at JavaOne last year, I had some mixed feelings. Let me explain.

I always thought that someday we'd need a standard for a "native" Java scripting language, with a Java-like syntax. I imagined that might grow out of the "Scripting for the Java Platform" (JSR 223) effort when that JSR was done, and that BeanShell could be a model for what that kind of a language could look like.

Some aspects of Groovy struck me as very similar to BeanShell: For instance, the Java-like syntax and the optional typing. But then Groovy goes off in very novel and interesting directions. I think that Groovy really wants to be an alternate programming language for the Java VM, and that working with Java is perhaps of secondary importance to them. By contrast, BeanShell is foremost a bridge between Java and the sorts of scripting problems javax.script deals with. The extent that BeanShell has become, or will become, a general-purpose programming language on its own, is yet to be seen.

The BeanShell JSR was prompted by the fact that the javax.script API will ship with Mustang and that the Java platform needs [scripting language] implementations for that API. The keepers of Java seem to think it's appropriate to ship a few, light-weight scripting languages with the platform. Since the core BeanShell is very small, only about a 150K JAR file, it fits that criteria.

Both Groovy and BeanShell will be available via the javax.script API. I do not yet know if BeanShell or Groovy will ever be bundled with the J2SE platform. For BeanShell, that is certainly the hope, but that will ultimately depend on what comes out of this JSR, and on the JCP. If and when that happens, I think will be a very good thing for Java.