Well, I will probably be more focused on telling about Rhino, as I myself am probably not that much interesting topic in itself. I am an independent IT consultant basically, and I do get involved into open source projects, mostly by means of having a scratch to itch in them. So, typically whenever I have problem to solve I look around for an open source solution for it, and usually I find something and usually that something needs improvements in order to be usable the way I want to use it, so I typically end up being involved in that project. This is basically how I got involved with Rhino as well. And Rhino is a JavaScript runtime engine that runs on top of the JVM. And it is maintained by the Mozilla foundation. It actually doesn't really have anything in common with the other engine, which is SpiderMonkey, that is being built into Mozilla's browsers. Rhino is a completely independent implementation, which is mostly used integrated into Java-based software.
2. Tell us more about Rhino, as I understand it is implemented in Java.
Ok, yes, it is implemented in Java, and what it does in most basic case is it takes the JavaScript programs, written in JavaScript obviously, and it can either interpret them or it can compile them to Java bytecode so they become just ordinary Java classes, basically first class citizens within JVM. And it also supports an offline compilation model where you can just pre-compile all of your JavaScript down to Java classes and just deploy them in a JAR file just like any other. At least in this regard it can be deployed as a quite optimal solution. Rhino is a library, so it does ship with an interactive shell but that's not how you will typically use it. It is a library, so you typically take it and you integrate it into your programs, in places where you would think it makes sense to add scripting capabilities to your program. You can basically just invoke the Rhino execution APIs at that point to have scripts executed.
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.
Well first of all these were not HTTP sessions, and second is that at the time there was no solution for having continuations in Java code proper. Today there is such a solution, it is an open source solution, the RIFE framework. But back then in 2003 actually it was not a viable solution. We had to look into solutions that are not using the Java stack but they can maintain their own stack so it's representable as objects and you can freeze it and Rhino turned out to be the best candidate on the JVM for that. So this is why we chose Rhino for our use case. And it also turned out to have other unexpected benefits. First of all is that what we developed was basically a platform on which further applications could be developed. And it turns out that it's quite easy to find programmers that know JavaScript. It's easier to find programmers who can write this in JavaScript than programmers who can write this in Java. There are less pitfalls, so to say, and also the other thing is that Rhino has its own security control architecture and otherwise you can control what objects to expose to them, so basically we could sort of sandbox those components that were implemented in script. So those people that had to work on those components basically were working in an environment that is less complex, and at the same time we could also more easily isolate the rest of the system.
5. If you were faced with the same choice today, would you still have chosen Rhino?
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.
Well you can embed it at really many levels. There are quite a lot of projects out there that are already using JavaScript. And they are mostly server-side JavaScript embeddings, where in web application frameworks that use Rhino they typically use it as a language to implement the action parts of the controller in a model view controller framework. There is a quite renowned application framework that is named Helma, it's developed in Austria, and the Austrian national broadcasting company uses it for its websites and several other mostly Austrian and German websites are also using it for that. You can use it for testing because it is really easy to actually create mock objects. At least with Rhino you can implement Java interfaces in JavaScript, so you can really easily and quickly create mock objects for your tests and it is actually quite easy to write a little adapter that will convert your scripts into instances of JUnit test classes, so that you can run them within JUnit as just any other test. And also there are other testing frameworks out there like HTTPUnit, which is used as the test driver for web applications and it needs to simulate the full browser environment complete with JavaScript. HTTPUnit also happens to choose Rhino as its technology for implementing the JavaScript in the emulated browser basically.
Right. Well, typical integration points tend to be everything that is not strictly performance-oriented, and on the other hand, you want to benefit from certain side effects. Such side effects would include quite easy code reloadability, because at least with JavaScript it is really easy to just reload the script file on the fly whenever it changes and delegate execution to it basically which, mind you, this is something that you can do with Java code as well, because I mean you can just use a custom classloader that you throw away after you have loaded Java class, and you can invoke the Java compiler dynamically or do bytecode generation, if that's your thing. In practice it's typically easier to do the same thing with the scripting API interfaces. And especially since Rhino actually does ship with JDK6, and JDK6 has a Sun-sanctioned API for generic scripting, you can just rely on those APIs to actually not only integrate Rhino in your program but actually to allow any scripting language runtime that is found in the classpath to be used interchangeably.
8. What sort of scripting of Java can you do with JavaScript and using Rhino?
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.
Yes, that's quite easily achievable even today, JavaScript is definitely the de facto language of the web because a runtime for JavaScript is universally available in every browser worth its salt today. It really boils down to "how easy you can make the communication between the client and the server" and at least with JavaScript we are lucky, because we have JSON, which is the JavaScript Object Notation. JavaScript has a very nice syntax for object literals and you can encode any object graph into a string that basically represents object literals, send it over the wire, and there are libraries for very safe unserializing of those; but if you don't have such a library, you can just evaluate that string at runtime and it would basically restore your object graph. So JSON is quickly superceding XML in browser to back-end communication, it's quite widely used with AJAX as well, so yes it's quite easy today to actually have JavaScript on the client and to have the JavaScript in the back-end using any web application server that can be scripted.
10. So what about JavaScript versus Ruby?
Well, I will have to admit my relative ignorance of Ruby. I don't know Ruby well enough to say too much about it, and I know that there are notable differences. Ruby actually has a concept of classes, so objects do belong to classes. JavaScript on the other hand does away completely with the concept of classes, and every object is just an object, is basically a bag of properties, which properties are either named by strings or named by numeric indexes and then you have an array basically. They say that JavaScript has a prototype-based inheritance, because every object can name another object as its prototype and then when a property, which can be a method as well, is not found on an object, then it is looked up in its prototype, and then in its prototype's prototype and up the chain. So these are the most notable differences deeply on the language level between JavaScript and Ruby, I think. There might as well be others, but I really am a bit ignorant about Ruby at the moment.
I heard about it. Well it is an amusing thing; it's always really nice to hear that people are using the Rhino runtime in rather unexpected ways. Steve actually did contact me some time last year, myself and others who are working on Rhino and it turns out that Google actually has a quite strong interest internally in Rhino, they are using it in several subprojects, either as a runtime or they are also building some tools for analyzing JavaScript that are using the Rhino's parser only. And it is really great that right now the biggest development force that we have on Rhino actually consists of Google employees. And they succeeded in bringing up Rhino to the JavaScript 1.5 compatibility level, so all JavaScript 1.5 features are now finally available in Rhino, and they are now working toward JavaScript 1.7, which has nice things like generators, deconstructing assignments and other maybe a little bit exotic features that really can save your day when you are coding and you are faced with a need to elegantly express a little bit more complex problem. So Rhino right now has quite a healthy and active development group and incidentally most of it is right now located within Google.
12. So what's on the roadmap for Rhino going forward?
Well, Rhino right now first wants to achieve the JavaScript 1.7 feature set. There is quite a bit of small internal improvements that we are making over time: better integration with the Java security system for instance, or basically replacing some older Java idioms with modern constucts because Rhino is an old project basically, and quite a lot of it was written in Java 1.1 days and we could maybe use replacing some of those innards with JDK 1.3, 1.4, 1.5 features. But on the other hand if it's not broken we don't really want to fix it too eagerly. There is the question of JavaScript 2.0 or ECMAScript 4 as it is also named, I don't know whether that is right now in the future for Rhino, whether the current runtime can be evolved to actually be a JavaScript 2 runtime or would we have to start with a clean slate there. I mean this question was not investigated deeply yet. But we'll have to see the JavaScript 2.0 actually gain some traction first and then we can think about probably spending resources on trying to adapt for that. So, I would say that a fixed roadmap is to gain JavaScript 1.7 features first.
13. What's your favorite computer book?
My favorite computer book is "Code complete", by Steve Connell.