How to choose a Java scripting language

Home

News: How to choose a Java scripting language

  1. How to choose a Java scripting language (17 messages)

    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.

    Threaded Messages (17)

  2. parsing/compilation times[ Go to top ]

    The Groovy times include the parsing/compilation overhead, which can be optimized away for scripts that are rerun often.
  3. Jelly[ Go to top ]

    Does anyone have thoughts about hooking Jelly (http://jakarta.apache.org/commons/jelly/) into your Java apps?
  4. Jelly[ Go to top ]

    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.
  5. Jelly Blues[ Go to top ]

    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.
  6. steady state performance[ Go to top ]

    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.
  7. 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
  8. Nice article!!! Great job by the author.

    Looks like pNuts is very nice, I downloaded their docs.zip based on this write up.
    .V
  9. Vic Pnuts[ Go to top ]

    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
  10. 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
  11. 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.
  12. Coyote news - excellent[ Go to top ]

    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
  13. Worthless article[ Go to top ]

    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"?
  14. 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
  15. No mention of BSF and JSR-223?[ Go to top ]

    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.
  16. JSR 223 should be stopped[ Go to top ]

    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
  17. 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)
  18. Read it[ Go to top ]

    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.