; Date: Tue Feb 28 2006

Tags: Java

Mustang, a.k.a. Java SE 6, is getting ready to bolt out of its corral. We've done a lot of good things in Mustang. There's a recent article published on devx.com giving an overview of changes in Mustang, plus we've published the official docs which you can browse.

There's one new feature that I want to talk about today, and that's the support for scripting languages in Java. I have some personal interest in language interpreters, from working on several projects involving interpreters. In my college years I wrote a BASIC interpreter (it's in the comp.sources.??? archives from around 1986 as "BASIC interpreter, needs work"). In the early 90's I spent a lot of time working with TCL. And I also got to do a little work with porting Microsoft's vbscript/jscript interpreter to Unix (I used to work for Mainsoft). And then, of course, I've been with the Java team for nearly 8 yrs (to be exact, Java's not exactly interpreted).

One attractive meme in all these different languages is the ability to take the same program and execute it on multiple operating systems. With the right software. I see this as being about freedom. There's the vendor lock-in that occurs when your software is compiled to machine instructions for a given operating system. But if your software is written in a language/runtime which offers portability, you have the freedom to choose a wider set of computers and operating systems.

How is this portability implemented? There's an architectural pattern that's followed in many "interpreted" languages. The language is implemented with two major modules. The first is a compiler to translate the high level language to byte-codes for a virtual machine. The second executes those byte-codes. Of course there might be other modules, such as to interface operating system facilities to a higher level abstraction.

In a few cases a language might be interpreted directly from the program text. This was the case for early versions of TCL, where the program text was reparsed each time a statement was executed. Last time I looked the TCL runtime converted TCL expressions to a string of byte codes for execution.

Obviously there's a huge efficiency gain when a language is executed from byte codes, rather than having the program text reparsed each time a statement is executed.

In the case of Java the intermediate language is the well documented class file format. Sun's Java implementation takes the class files and Hotspot will dynamically decide which parts are executed most often, and compile those parts for the given CPU/OS currently executing. This is why I earlier said Java is pseudo-interpreted, as some parts of your application will be interpreted, and other parts will be machine code instructions running at native execution speed.

Mustang offers an exciting possibility for language authors.

Think about the architectural pattern I described. Anybody who has a hankering to write a new language has two problems. One is the language design, and the other is the most efficient way to execute programs written in that language. What Mustang offers is a way for a budding language designer to skip that second step, and just focus on their language design.

Consider: jrunscript

One of the options is "-l language", and it's silent on which languages are supported. That's because the underlying technology allows "any" language to be plugged in. By default the javascript language is included in the JRE. The javax.script package, new in Mustang, allows you to plug in other languages. ( see the javadocs)

I'm not going to go into much depth with this feature, if only because I've not yet used this feature. The language author embeds their language using the ScriptEngine interface, using the service provider mechanism to tell Java about their ScriptEngine. The system allows for multiple scripting languages to run inside the same Java virtual machine.

Apparently it's a little too soon, still, for many languages to be implemented with the javax.script interface. Doing a web search I see some activity. For example BeanShell can hook up with javax.script. An exciting possility is for a PHP/javax.script implementation (see php-java-bridge).

UPDATE: Stevey's JVM Language Soko-Shootout is the beginning of some interesting research into JVM's support of other languages. Unfortunately he was hired by Google, which cut short his research.

Source: weblogs.java.net

Comments

Comments are listed in date ascending order (oldest first)

Java is certainly making progress here. I would like to see an IDE that treated Java and other scripting languages as closer to being peers. If a scripting language can be compiled into a class--and some can--then the IDE could give developers the same sort of help that is available for Java. I'm talking about import resolution, method completion, etc... Posted by: coxcu on March 01, 2006 at 06:18 AM

I have mixed feelings about this. On the one hand it more clearly differentiates between Java the language and the broader 'Java' platform. It means that not only is Java CPU/OS-independent, but the JVM itself gives programming language independence (as does .NET). On the other hand there's a worry about JVM-bloat. Just how big does the JRE have to get before we say enough is enough?

Posted by: pan on March 01, 2006 at 08:25 AM

"Big" is a very vague term. Big can mean:

1. number of bytes required to download the JRE
2. number of bytes the JRE takes up on disk
3. number of bytes a JVM occupies in memory
4. number of methods the developer has to choose from
5. number of concepts the developer has to deal with
6. and so on ... All of these are important to different people at different times. Sometimes they correlate and sometimes they don't. In the long run, reducing complexity will be more important to Java than increasing efficiency.

Posted by: coxcu on March 01, 2006 at 09:06 AM

pan, The capability to support other languages has always been there. For example, Kawa, the Scheme implementation for Java, produces bytecodes directly. What javax.script does is make it easier for a language implementer to use the Java environment.

One thing I didn't mention in the posting -- it offers script writers a new twist to writing applications. You can more easily make a mixed application, where some parts are an object oriented class library with all the Java language features etc, and you can write thin scripts on top of that. For example I'm sure PHP authors might appreciate the ability to ride on top of a hugely scalable platform as JavaEE. (or might not... depends on their business needs I suppose)

I think that the javax.script package itself is a small addition. However the "bloat" addition in this case would be the javascript interpreter that's now bundled with the JRE. Hurm. But, believe it or not, the Java SE engineers do watch several platform "size" metrics and guard against growth in the size. Obviously it's hard to add features without growing some of the size metrics.

Posted by: robogeek on March 01, 2006 at 09:36 AM

coxcu, one of the memes our management repeats frequently is about -- whenever we create some feature, there has to be a full solution for that feature. That means documentation and tools support among other things. Given that, one should expect Netbeans will sprout features like what you describe. If not, then someone in the organization isn't living up to management's requests. Posted by: robogeek on March 01, 2006 at 09:39 AM

@coxcu Shameless plug: I just released the EclipseShell project which is a basically an adapted editor that can act as a shell for various dynamic/scripting languages. It currently has support for Beanshell, JRuby and Javascript (Rhino). It is not a fullblown environment for these languages, but these are worked on, eg with the RDT project for Ruby Posted by: murphee on March 01, 2006 at 04:05 PM