Links

Patrick Mueller elsewhere: muellerware.org, twitter.com/pmuellr

Thursday, August 31, 2006

Scripting Languages in Java

Joe Gregorio has a nice, short article describing Python coolio stuff to Java programmers; Dave Johnson responds with some links to scripting languages implemented in Java that can do the stuff that Joe talked about, so you can have your cake and compile Java too!

Joe's article is great, will definitely have to keep that link handy, especially now that I gotta new job assignment involving scripting.

So I've actually played with some of these scripting languages in Java, and was even on the Groovy JSR Expert Group for a short time (a funny story why I left, that will cost you a measily beer). Note my most recent experiences were with Rhino playing with Eclipse Monkey. Some observations:

  • If you're expecting to call into existing Java classes from your scripting language, one thing your likely going to miss in your scripting IDE are things like code completion. Assuming you even have code completion for your scripting language (hard task without easily obtained string typing information that Java has), it's highly unlikely that you'd get code completion when you are calling out to Java. Which is where you really need it. I found that without code completion, trying to talk to existing Java code, I had to leave a JavaDoc browser open, and was sometimes cutting/pasting stuff between that and the editor.
  • There are a few language level mis-matches. I know Jython and Rhino had/have issues with Java arrays. Any time you needed a Java array, to pass into some existing API, there was some kind of little piece of poop you had to run. Was quite unnatural.
  • Environments can be unfriendly to the limitations of scripting. I've tried a couple of times to do some scripting of Eclipse, in the plugin sense, and Eclipse just doesn't make this easy. Expects you to have classes all over the place, based on gunk in .xml files, and without pre-compiling my scripts into Java, I was going to have to have at least some small Java stubs just to have someone for Eclipse to talk to, and then the stub could invoke the script.
  • Debugging. argghhh
  • Reload and run. Typically when you're scripting, it's not just that you don't have a compile step, but you also have a very short test restart cycle. For JavaScript in a browser, typically you're talking about F5, and then maybe some work to get you into a testing state. In Smalltalk, we'd just change the code, run the test again. In Eclipse, writing plugins, you have to launch a new workspace, debug away, and then generally have to bring the workspace down before making significant code changes. Hot code replace in Java is definitely sweet, but it can't tolerate class shape changes, and those happen far too often.
  • I've often thought of all the languages Groovy was probably going to be the easiest to use simply because it had no non-Java version it ever had to live up to. And had first class notions of dealing with Java.

I really, really wanted to use scripting in some, I thought, fairly obvious places, but it's always ended up just not working out for me. What a bummer.

If I still thought there was hope for scripting Eclipse, I'd definitely check out Aptana, based on Bjorn Freeman-Benson's glowing descriptions. Instead, I'm going to try living out of TextMate for a while ...

BTW, Tim Bray has an interesting set of blog posts on his experiences with JRuby.

No comments: