John O'Conner's Blog

Scripting on the Java Desktop

I've ranted a little about scripting languages in the past, and although I still twinge at the name "Groovy", I'm beginning to recognize the utility of scripting in the Java platform. I even think desktop applications can benefit the most from a scripting environment.

What benefit? For starters, not everyone knows the Java language. Yeah, it's sad but true. Some developers are still hanging on to some other language...but we like them anyway. And we could really use their skills if we could just figure out how to integrate their code...too bad it's in PHP, Ruby, Perl, or JavaScript. However, now JSR 223 makes that possible. OK, maybe JSR 223 doesn't solve how to integrate people into your project, but it sure helps integrate scripting language components. And if you have people that can write code in JavaScript, PHP, Perl, Ruby, whatever, you can pull some of that stuff into your Java applications. Java SE 6 implements the java.script package APIs that make this possible.

In my opinion, the most important benefit by far is that you can allow customers to configure, enhance, tweak, and otherwise hack your applications. Oops, shouldn't have said "hack." Rewind. Restate. You can let them add customized functionality after you ship the product. The gentler learning curve for some scripting languages allows users to collaborate with you to create configurable, dynamic applications. That's good, right.

I put together an article that mentions other benefits of pulling scripting languages into the Java platform. The article also describes how to use the scripting APIs available in Java SE 6 (Mustang). The article Scripting for the Java Platform is on Sun's Java developer website. Sample code and a downloadable demo application give you lots of examples to understand the new scripting APIs. Happy reading.

Comments

• I recently read a couple of articles about scripting. I downloaded Groovy and Jython and equipped my Eclipse with appropriate plugins. But till now, I just could take the time to play a little and get things to work.

  In the not so distant future I may have to develop an application equipped with a set of mathematical operations that users can combine, extend and build upon. My feeling is, that an embedded scripting language could be of great benefit. Because I've been prefessionally working with PHP until I catched the Java train I know that often so called scripting languages aka dynmaically typed languages (Perl, PHP, Python, Ruby, ..) have a fair productivity advantage over statically typed languages as Java, C#, C++, ... Even MS recognized it and devleloped IronPython as language on top of .NET 2.0.

  What I don't know because of my lack of experience in using embedded scripting languages in Java is, how ot all fits together in the real world. What are common places in a Java desktop app where you can benefit from scripting and how do you integrate scripts in terms of application architecture (thinking of MVC and design patterns)? Another big question mark is which language to choose. There is often-hyped Groovy but there's also a lot of criticism about this particular language. Then there is JRuby, Jython, BeanShell and a lot more and even more to come. If a team doesn't have a strong background on one of those languages, which would be best? You wouldn't want to evaluate them all, would you?
  The weakness of Groovy to me is, that it is ONLY a Java scripting language. You'd have to learn it and could use it only in Java environments, whereas Ruby and Python are independent and already have a huge code and user base.

  If I had to make a choice now, before taking my time to evaluate, I'd probably go with Jython. It's good, there's an Eclipse plugin, there's a lot of Python experience in the community and on the market and there is IronPython (just in case ...).

  Another thing I'd like to know is: How does debugging a hybrid desktop application work? Is there any difference from 'conventional' Java? In dynamically typed languages you tend to find bugs at runtime, whereas a lot of potential for bugs in Java is eliminated at compile time or even on the fly (as you type in your favorite IDE like Eclipse, Netbeans, IDEA, JBuilder). Does it mean you need to spend more time testing and debugging your apps?

  Very interesting read if you'd like to know more about Python in general:
  Python and the Programmer - A Conversation with Bruce Eckel, Part I
  The Zen of Python - A Conversation with Bruce Eckel, Part II
  Type Checking and Techie Control - A Conversation with Bruce Eckel, Part III
  Python and the Tipping Point - A Conversation with Bruce Eckel, Part IV

  Posted by: pronger on July 26, 2006 at 12:07 AM

• A few years ago I wrote a rather large application called Jext (http://www.jext.org) that uses Jython internally. A lot. In fact, every time you click on a menu item, a snippet of Python code is invoked. Since Jext is a source code editor, I did this so I could code the menu actions within the dev version of the app itself. Hitting a special Debug menu would just reload the menu with the code currently opened in the editor. Anyway, I've used Python quite a lot in the past and yes, I found out that dynamic languages need more thorough testing than statically compiled ones. Some silly problems (I'm not talking about logic errors, but syntax errors) might occur only at runtime and it's a pain when they are burried in seldom executed branches of your code. TDD is a king in this case :)

  Posted by: gfx on July 26, 2006 at 06:01 AM

• John, I've been experimenting with adding scripting to NetBeans along the lines of what gfx did with Jext. I've also extended this to Jackpot. See

  
  http://blogs.sun.com/roller/page/chuk?entry=netbeans_scriptengine_update

  and

  
  http://blogs.sun.com/roller/page/chuk?entry=scripting_jackpot
  

  Posted by: chukmunnlee on July 26, 2006 at 11:14 AM

• Groovy is pretty cool too. There was this instance when we needed an evaluation engine for our rule engine and groovy came in quite handy. While this could have been done in java itself, the fact that this was a rule engine and it should be possible to create rules and use them instantly, made Groovy very attractive. It was really fun working with groovy though the idea was dropped. Iam still on jdk1.4.2 though.

  Posted by: ovisvana on July 26, 2006 at 08:29 PM

• In a parallel universe, scripting of desktop applications has been used every day by millions of people for the last ten years.

  Posted by: cayhorstmann on July 26, 2006 at 09:32 PM

• Mr. Horstmann, although scripting for alternate platforms has been around for the last ten years, a well-defined, standard scripting API for the Java platform has not been available. So, if you're pointing that out, I guess I simply agree. If you're trying to say something else, I guess I'm not getting the message...can you clarify?

  Posted by: joconner on July 26, 2006 at 10:15 PM

• Mixing and matching languages within the same project is generally a bad idea, IMHO. There are some exceptions, like when a HLL employs a tight low level module (via JNI, in Java's case), but as a developer if I inherit code written in half a dozen different HLL's (where each programmer got to choose his own favourite and stick with it) then I'd be tempted to junk the lot and start over.

  Scripting is very useful in desktop applications, but generally it should be employed for the benefit of the application or the end user, not as a convenience to the programmer. ;)

  Posted by: javakiddy on July 27, 2006 at 03:13 AM

• javakiddy, I agree with you. In the actual article, I try to make the point that scripting can help you collaborate with end users to create dynamic, configurable applications. I believe that's the largest benefit.

  Posted by: joconner on July 27, 2006 at 09:28 AM

• Not sure why this comes to mind, but: There is scripting within an application (think Word macros), and there is scripting to orchestrate the behaviour of multiple applications (think Unix shell programming).If we expose the objects/services within our applications for use in the "orchestrate behavior" sense of scripting... then we're pretty much adopting the SOA paradigm.Surely we can come up with a better scripting language than BPEL-JohnR

  Posted by: johnreynolds on July 28, 2006 at 07:55 AM

• Sorry about the late reply...I agree with you that it is useful to have a standard scripting layer in Mustang. When I read " I even think desktop applications can benefit the most from a scripting environment.", I was a little taken aback. If you follow the money, far more is spent on scripting Office than on any other app, desktop or server. So it should hardly come as a surprise that desktop apps benefit from scripting. Sometimes I feel as if the Java world is a closed and cultish world where we prefer to ignore the much larger world around us. At any rate, that was my impression on a grumpy morning :-)
  

  Posted by: cayhorstmann on August 01, 2006 at 09:15 AM

• @cayhorstmann:

  There may be a lot of money involved with office scripting, but I don't think you can transfer this particular case to every other desktop application. Office suites are like swiss army knives and you'll hardly find any other applications that are as important to office productivity these days and could make a use of similar customization capabilities.

  Posted by: alarenal on August 01, 2006 at 10:57 PM

This work is licensed under a Creative Commons License.