views:

313

answers:

1

I'm designing a Framework which I want to attach to the scripting language API to make it more versatile and easier to use (for some things I really prefer the scripting way myself ;). With languages like JRuby, Jython or Rhino (JavaScript) there are interpreters for many popular scripting languages available and as far as I read, all of them implement the Java Scripting language API to embed them in your Java application.

Do you have experience with running it that way? I'm especially interested in handling e.g. associative arrays (or Java Beans). How is the performance (e.g. compared to a CGI like approach or the native Java way)? Would it be easy to switch between the different interpreters (of course it is an API specification but I still don't know on how to handle language specific issues)?

+5  A: 

I have run Rhino, Jython, JRuby, and Groovy. There is the obvious language difference between them all and performance is pretty slow across the board. I've found that Groovy was the easiest to create a domain specific language (DSL) for my application. Groovy was also the easiest language to control in terms of package accessibility and runtime variables but required using Groovy API to do it instead of JSR-223.

I feel like the Groovy tooling/documenation/api meshes better with the JVM, but certainly ruby/python have quite a following and the syntax may be more comfortable for some. Ultimately I'd try them all out in your framework and choose one. Multiple scripting languages sounds nice but might be a headache to debug/support/transition.

after though: You could check into BeanShell

basszero
Thanks for your input. I agree that supporting multiple languages would be a hassle and I was eyeing at Groovy already anyway (especially because Grails already offers some of the functionallity I intend to use). But since you say that the other interpreters are quite slow I will try the Groovy API before the JSR-223 candidates.
Daff
Don't get me wrong, all of the scripting languages are slow but you're probably not picking one for speed
basszero
Hm got it. Makes sense and of course it is a time/comfort tradeoff. But any scripting language would benefit the Framework for usability reasons.
Daff