If you are considering hooking a scripting interpreter into your Java application, the hardest part is choosing which one to use. David Kearns describes some of the issues that come with supporting a scripting language in your Java application and compares Groovy, JudoScript, Pnuts, JRuby, Jacl, Jython, Rhino, and BeanShell in a variety of ways to help you make the right choice.

Read Choosing a Java Scripting language.

In related news, on February 10th, JSR 223: Scripting for the Java Platform Released a Public Draft. The JSR is concerned with how to write and package Java classes that will be accessible from different scripting engines, which should make the integration effort easier.

The Groovy times include the parsing/compilation overhead, which can be optimized away for scripts that are rerun often.

Does anyone have thoughts about hooking Jelly (http://jakarta.apache.org/commons/jelly/) into your Java apps?

We tried to use Jelly as the template engine for a webapp 2 years ago. The component architecture for defining new tags was simplier than JSP tags, that's the primiary reason we want to try it.

Sadly, we had to move away from Jelly after a while because it had a very bad memory leak problem when parsing scripts. It seems the problem has been fixed now, but we are not going to move back to Jelly because we are now happy Tapestry users.

I had to use Jelly on one project. I wrote some closed-source Maven plugins.

I tried to avoid Jelly as much as possible, and put most of my code into the Jelly tag object (written in Java).

Jelly seemed a bit unpleasant to me. (It just never seemed quite baked.)

Also, I heard that Maven 2.0 rewrote most of the plugins in BeanShell. A lot of the plugins were written in Jelly.

The tests also do not reflect the performance characteristics of the bytecode based scripting languages, which can take advantage of the JIT and hotspot compilation available in the JVM. If Groovy and BeanShell compile into reasonable bytecode that is anywhere close to javac, I don't see why the steady state performance of these languages would not be equivalent to Java code, when parsing/compilation time is factored out.

If Groovy and BeanShell compile into reasonable bytecode that is anywhere close to javac, I don't see why the steady state performance of these languages would not be equivalent to Java code, when parsing/compilation time is factored out.

Ben,

I can't speak for groovy or beanshell, but I know that the compile-to-bytecode option for jython generates a class file that requires the jython interpreter classes in order to run. So it optimises away the overhead of parsing the script text, but every variable in the script is still wrapped as a PyObject, so performance and footprint will still be slower.

Take a simple example in python (the exact details may be inaccurate here, as I'm writing off the top of my head, but the general principles are true)

a=b+c

Jython will create three PyObjects for a,b, c and then evaluate a by calling the _add_() method (I think I've got that name right) of b with c as an argument. _add_() will figure out that c is wrapping an integer, and then call the inbuilt add operator of the VM.

In java, compiling the code

int a=b+c

will cut straight to the inbuilt add operator without faffing about with PyObjects or anything else.

Needless to say, your performance will benefit. The trade-off is the longer development cycle if using java rather than jython or similar.

Implementing the type of compilation that jython does support is relatively straightforward, because it reuses the existing interpreter workflow, but spits the bytecode out to a .class file instead of into the JVM. Implementing a compiler that strips out the PyObjects (or equivalent in any other scripting engine) would require a lot of new code, and a lot of effort!

Dave

Nice article!!! Great job by the author.

Looks like pNuts is very nice, I downloaded their docs.zip based on this write up.
.V

Vic,

I read the article as well. Nothing in the article seemed to make Pnuts all that interesting to me.

What in the article made Pnuts so appealing to you?

Did I miss something? Care to share?

.R

I wish this article existed some years ago when I was looking at Jython as an embedded script interpreter for my Web test tool. The article covers the important parts of an architect's decision points. It wasn't mentioned in the article but it's worth pointing out that these Java Byte Code based languages are very stable. I've had a Jython test script monitoring a Web site for 6 months or longer without fail.

Now for my gripe: Why doesn't Sun get the benefits of multiple languages running on the JVM? It's a clear way to even the playing field with .NET, and it helps attract the attention of all those PHP and Perl scripters.

Tim Bray at Sun has been trying for the past year to get Sun to at least endorse the idea of dynamic scripting languages on Java. But he's getting little support.

And then there's the inevitable disappointments on dynamic scripting from Sun. For example:


Dear Frank Cohen,

 Sun Microsystems, Inc. and the JavaOne(sm) Conference Content Team are grateful for your proposal to present at the 2005 JavaOne conference. The high quality of submissions made the selection process extremely difficult. We regret to inform you that we will be unable to accept your proposal entitled ' Dynamic scripting languages BOF (Jython, Groovy, Perl, and many more) '.

 Thank you very much for your submission. We appreciate your continued support of the JavaOne conference.

 Sincerely,
 JavaOne Conference Content Tea


Oh well.

-Frank Cohen
http://www.pushtotest.com

Now for my gripe: Why doesn't Sun get the benefits of multiple languages running on the JVM?
Funny you should ask. See what I just wrote on my blog.

Tim Bray at Sun has been trying for the past year to get Sun to at least endorse the idea of dynamic scripting languages on Java. But he's getting little support.
Again, funny you should mention that, have you seen what Tim wrote today (no, not the 'boring' thing)? I don't think he would agree with you.

I'm sorry your session wasn't accepted, neither was mine. It has nothing to do with not liking scripting languages though. It would be great to have your help with Coyote ...

S.

Thanks for pointing me to Tim's blog on the news that Coyote - a Groovy and Jython module for NetBeans - is available. I'm downloading it now.

-Frank

I worked a lot with jython, and it is an excellent choice.
The entire java world combined with the entire python world.
D. Orbach
javasight - java news & books

Well, the entire Java world combined with the entire Python world of 2-3 years ago. I'll be much more excited when I see Jython updated to the current Python version.

I've heard this complaint about Jython not being up-to-date enough for some developers. From my experience, most of Python's advancements over the past 2 years have been to add libraries that wrap-around the core language. I haven't seen the core Python language change in a long while. Many of Python 2.2, 2.3, and 2.4's changes are extensions to make it easy to use Python to manipulate XML, to implement Web services, to implement collections support, and to work with Windows. As a Java developer none of these interests me because anything that's on the classpath is available to my Jython scripts as an object. And I mean everything, all of the J2SE, J2EE and J2ME objects. So I can use the JAX pack for XML, Apache Axis for Web Servivces, real Java collections, and JNI if I need to deal with Windows. I'm happy with Jython 2.1.

-Frank

Actually, I think Python changed quite a bit. It is my understandign that they added block closures and continuation to Python to compete with Ruby. Thus, Jython does not have this language support.

This seems like a pretty major change to the core. I hope this is something that gets added to Jython.

It looks like Groovy has this support already. This makes Groovy very Rubyesque.

The more I learn about Groovy... the more I hope it takes off.

Disclaimer: It has been a while since I followed Python closely. I am not a Ruby expert.

Here are some thoughts and comparisons of Jython and Groovy:

http://www.jroller.com/page/RickHigh/20050315#is_the_groovy_language_groovy

There are several things I could mention but I'll just point out the most glaring one:

you can not learn anything about the performance of a language by using micro benchmarks!!!

Do we need to keep providing links to this excellent IBM article that explains why?
 
http://www-128.ibm.com/developerworks/java/library/j-jtp02225.html

This article is about Java but reading you'll understand it applies to other languages as well.

Knowing how to make and read graphs seems to be difficult as well because with cummulative measurements it's impossible to see if there's only one benchmark that makes up for 99% of the time taken while the others might be blindingly fast.
The article also says "Rhino, Pnuts, and Jython were consistently the fastest, followed closely by Groovy, then JudoScript". What? Groovy is almost 3 times as slow as Rhino! And Judoscript is even 7 times slower! How on earth can this be "closely followed"?

look at http://www.xmoon.org

Hello,

  If you want to choose a scripting language according to popularity allow me to highlight the Viva! Java Scripting Language of the Year 2004 Award. See http://viva.sourceforge.net/republic/?p=56 for details.

  - Gerald
_________________________
Gerald Bauer
Thinlet World - http://thinletworld.com

How you can write an article on Java scripting without mentioning either BSF or JSR-223, both of which make the choice of scripting language somewhat moot, is beyond me.

Bsf is really good. i have already use it with XMoon.

Here's my blog on JSR 223 from last year. -Frank


Sun is promoting a new openness to support scripting languages in the Java platform. See details at http://www.jcp.org/en/jsr/detail?id=223 .

Frank Cohen recently wrote an open-letter to the Jython community urging Sun to rewrite JSR 223.

I am using Jython embedded in my TestMaker open-source project as a utility and framework for building intelligent test agents to check Web-enabled applications for scalability, performance and functionality. I am trying to convince developers, QA technicians and IT managers that Python is their lingua-franca to build better software. Details are at http://www.pushtotest.com/ptt.

In my opinion JSR 223 is not worthy of support. JSR 223 implements a very un-Java like way to bridge Java objects to script language functions. 223 aims to provide a native interface to make calls from a Java object to a limited number of common scripting functions. While there may be times when a native interface is useful, I would never like to include a native interface in my production-ready code. It's asking for problems, including:

1) Weak exception handling. If my scripting language interpreter runs externally to the Java VM then how do I handle recovering from an exception in the interpreter? 2) Slower performance. Native interfaces take processing time and memory to make a call to an external function. 3) Fewer expert resources to help me code. Look at how few engineers there are with production JNI experience.

In my view, JSR 223 should be restarted. I believe Jython's use of Java byte codes is a much better design.

Jython compiles Python scripts into Java byte codes. The Python script in Jython is 100% Java and runs as native Java code through the VM. Imagine if JSR 223 standardized the way script languages compiled scripts into Java byte-codes. You could have PHP, Python, Ruby, and anything else... and they would all be 100% Java.

Support for Java byte-codes is important in the middleware space, where J2EE and .NET are battling it out for developer mindshare and support. Microsoft has done an excellent job at building its CLR virtual machine to support multiple object-oriented languages. The Java platform would be so much better with multiple language support... all running on the Java VM.

-Frank Cohen

I've been thinking about this stuff recently. Dion did an excellent job preaching the gospel of Groovy at the TSSS in Vegas.

My musings about Groovy after attending Dion's talk.
http://www.jroller.com/page/RickHigh/20050315#is_the_groovy_language_groovy


The Coyote stuff looks interesting. I like the fact that Coyote provides IDE support.

I still need to read the article. :o)

I read the article. I wrote a similar set of article covering Jython (JPython at the time), BeanShell, Rhino, and NetRexx for the JDJ. Pnuts was mentioned but not highlighted.

The piece that is really missing is the tool support (code completion, debugging, integration as Java classes). I understand that Coyote provides tools support, but it does it on the NetBeans IDE platform.

Nearly all of my clients are using (in order): Eclipse (80%), IBM WSAD (Rational Rad) (10%), IntelliJ (5%), and then Borland (2%). I used NetBean before I started using Eclipse, and I liked it.

There is an Eclipse plugin for Jython, and a Eclipse plugin for Groovy.

Excerpt from my blog on Dion talk about Groovy....

Dion felt JSR-241 should not exist because Groovy is still rapidly evolving. I agree to a point. Dion also felt that debugging Groovy was hell. Dion also felt that for some tasks Java does not make as much sense as a higher level language like Groovy.

 

There are some benefits of Ruby over Java, but Groovy and Ruby seem to be on par for language features.

 

"When will I use Groovy? I will use Groovy when my IDE provides good support for Groovy. I want code completion, break points, refactoring, and easy integration with the rest of my Java classes. Then I will use Groovy. I am assuming of course that Groovy matures and can be used in production applications."

http://www.jroller.com/page/RickHigh/20050315#is_the_groovy_language_groovy

"Dion had an intersting idea. I think it was Dion. Why doesn't IBM, Sun or Oracle hire James Strachan and let him work on Groovy full time?

It looks like the Java platform is winning the war against the .Net onslaught. Groovy could help beat back the M$ hordes even further. Groovy needs some full time love and affection to help it mature and grow."

If Groovy lives up to its promise, I think I would prefer it to Jython. Dion did an excellent job promoting Groovy. It got me interested again.