Ok, my use case was something a little bit maybe exotic. I really needed to have a system that is able to run an absurd amount of concurrent processes, I think in tens of thousands at once. And you obviously can't do that with Java threads because they don't scale to ten thousand threads at any one time. But what you can do here, you can use continuations. Continuations are something that is a really nice concept but it's not really as widely used in the industry as I would like it to be widely used, and at that time there was a version of Rhino that actually had continuations, which was the Apache Cocoon, which is a private fork of Rhino. And I actually started working with then-current developers of Rhino to add this continuation support in the mainline Rhino. Basically continuations are the objects that represent your stack trace, so you can just capture a snapshot of your stack trace, save it away and then restore it and run it later, and you don't have to keep a physical thread running for that particular stack trace at all times, you can just freeze it into a database and restore it afterwards and that really allows you to scale to really any number of concurrent so to say virtual threads running at any one time.
I am not sure, I might choose it for exactly because of these other benefits that I just told you about, which are sandboxing and exposing an easier programming language to people to work with. Solely because of the continuation support I actually might turn to RIFE, but these other benefits are quite significant, so it would still have to be weighted pro and contra.
A typical thing that you might want to script is UI, because you can just assign actions to your buttons or whatever change events, and you can have the interfaces for those ActionListeners, actually be implemented in script and you can have the behavior changing without actually restarting the program. Or the other possibility is, really a similar example, if you are writing a web application and you are using a web application container, you can also script your actions and those actions will then, again you gain the benefit of being able to just modify the script file and have the action be modified at runtime without the need to restart the servlet container. But you can just as well choose to push parts of the business logic into a script especially if it's a sort of a policy that changes fairly often, which can happen with business rules, because there might be promotions or whatever else that the business is doing, so it has to be able to quickly change the mode of operation. Also what you can do is dynamic languages typically lend themselves quite natively to building internal domain-specific languages, and again if you basically have a library of functions that implement a nice domain-specific language, then you might end up actually being able to express your business logic quite concisely using a script. Again this is not really Rhino specific; you can gain the same benefits by using either Ruby or the Python's Java binding, Jython. But this holds generally for scripting languages basically.
My favorite computer book is "Code complete", by Steve Connell.
A few points from the interview:
- It has its own sandbox to impose security restrictions
- It comes bundled with Sun's Java 6 implementation
Sling is a fairly new project, and is still evolving quite a lot, so anyone who wants to have a look at it is very welcome.