Hello. I am Ola Bini, I am from Sweden, I work for ThoughtWorks. I am one of the JRuby core developers. I am the author of "Practical JRuby on Rails" from Apress, published a month ago.
2. Since you mentioned your book, why don't you tell us what your book is about?
It's a practical introduction to how to use JRuby and Rails. It's project driven, meaning that you won't get all the theory, you will get practical examples of how to integrate JRuby, how to work with JRuby and Rails and combine Rails with enterprise style stuff from the Java environment, doing stuff like XML in a way that doesn't use Ruby's XML libraries, interacting with enterprise application EJBs, things like that.
3. Is it structured as a tutorial book?
Yes mostly. It's structured like four different projects. We go from scratch, from each one and gets more and more advanced and goes to all the features introduced piece by piece.
4. Can you tell us about you role on the JRuby team as a committer?
Yes. What I do, usually my part in the team is mostly about extensions, since JRuby needs to re-implement all counter parts to C extensions; that is a huge part of the implementation. So that is one of the things that I've been doing quite a lot. It started out when I re-implemented YAML libraries for JRuby one and a half -two years ago and since then I've been doing lots of stuff. I am one of the committers responsible for ActiveRecord JDBC, the component that makes possible to use JDBC drivers from Rails and I'm involved in all parts of the implementation, but that is the focus mostly. I've been recently working quite a lot on our regular expression engine too and obviously I do bug fixing of all kinds, like all of us.
The problem here is that Java's regular expression engine is a really good engine, but it doesn't really match the way Ruby works and since we need our implementation to be totally compatible in all ways you can imagine that presented a few problems. The first time we really found a problem was with one of the Rails regular expressions that is responsible for parsing multiple data. This regular expression explodes on Java because it uses the Java regular expression engine uses a recursive algorithm and for a large input for certain kinds of regular express it blows the stack. So we decided to find another solution and we went with something called: JRegexJRegex for a while. It was a dormant project when we found it, it had all the features we needed, it was actually faster than the Java regular expression engine and most important of all it was not recursive in nature. So we appropriated it, fixed a few bugs in it and we've been using it as our main regular expression engine for both the 1.0 release and 1.01 and 1.02 and also it's still in 1.1 beta release and it's a good engine, but we started to come up with places where it still isn't enough. In this case we talk about performance and there is some really pathological cases where the engine can't really find... A typical example: say that you have a really long string and you have a regular expression that does a backtracking search, but a part of the regular expression is a constant string. If that string can't be found in the long string what MRI does is basically stops before it. It doesn't try to go through the whole string backtracking because there is no idea, there is no way the regular expression can match anyway. JRegex doesn't do that so in some cases we have regular expressions that just kills our engine.
6. So did you basically take over the JRegex project?
Yes, we appropriated it and put it into our archive. We've been meaning to get back, send back and publish the changes, but since we've been doing lots of stuff and a few other things we've added to the engine have been specific for JRuby. We've been forced to take out a few features that don't really fit in the Ruby engine.
Oniguruma is the next generation, regular expression engine that MRI or rather Ruby 1.9 uses. It's fully internationalized. It can use basically all different multibyte character and codings you can imagine. It also supports really advanced features, name grouping, look ahead, look behind, all these kinds of things you can do recursive regular expressions quite easily. It has some really good features. It's also very much larger than the current regular expression engine.
We are planning and we are working on restructuring our implementation to be both possible to be 1.8 and 1.9 compatible. The way we are looking at this is taking some on the typical 1.9 features. For example 1.9 takes literal arguments to a case statement and inlines that, it doesn't call the triple equals That gives better performance in those cases, but it's a breaking change compared to Ruby 1.8. What we will do is take all these changes, basically add flags for all of them so you can selectively choose which part of 1.9 you should be able to use. As a part of getting the regular expression compatibility right for 1.9 we have one of our team members who is working a port of Oniguruma to Java. It's interesting work, it's a really large port and he is not finished with it yet, so we'll see what happens, but if all pans well, that will probably be our main regular expression engine in the future. So what we will do is when we've run in 1.8 compatibility mode we will basically just get to the part of it so we get the same kind of functionality as in 1.8 and hopefully this will also solve the performance problems and give us scalable regular expression performance that works more like the way MRI does.
Yes, absolutely. It's been an interesting time since I started and it's been really obvious that it's an enterprise that JRuby really has its match. In many other cases people don't really need the capabilities of running on Java, but in enterprise it's almost always necessary. In many cases we have these really large investment banks; they don't allow anything else into the system. You can't run anything in their main frames and their computer centres if it's not Java.
12. Is Ruby considered just another library in that circumstance?
In this case it works out that way and even if we tell them what's actually going on it's fine because it runs on Java, but in a few cases, one of my colleagues, Josh Graham, told me told me a few days back about one of his works. He's been doing some JRuby work for us, for one of our clients and he basically said that he told the clients: "This is just a Java project. We have these static text files that are just configuration." I am not sure if I agree with that kind of sneaky trick , but it works and it allows us to deliver more functionality in a better way, quicker and with better turnaround to our clients and that is something that is really good for both us and them.
13. Under what circumstances do you think that JRuby could become the dominant Ruby platform?
I don't think that will ever happen. There is a certain stigma to the Java platform in certain camps. For example typical small scale scripts where you need something to start quickly and just run a few seconds. In those cases the JRuby startup time can be a problem because you need to start a JVM and then you need to start JRuby and it takes some time. We have some solutions to that. We recently added something called "nailgun" which works for several cases to improve the startup performance by almost a magnitude, so there are ways around it, but in many cases there is just no need for it. On the other hand if JRuby really becomes significantly faster , for several benchmarks we are already faster then 1.9, but on other benchmarks, for example typical Rails benchmarks, we are in most cases a little bit faster, but not much faster then the regular Ruby implementation. So if we manage to turn that around and get significantly more performance out of Rails and of these kinds of large applications, that will be a real boon to JRuby adoption, I think. But the Ruby community doesn't really care that much about performance, so it's more about getting things done the best way possible.
That is a hard question really. What I do know is that I really love the Ruby community. The Ruby community is without question absolutely the best community I've ever been part of and it's awesome, but it is kind of hard to compare because the Ruby community and the Java developer community, they move in totally different worlds. The Java application developers I've been around are mostly in the enterprise area. I would say that most Ruby developers are more passionate. There is passion and there is pride in a different way in the Ruby community compared to Java. I feel for me personally, I see that the Ruby developers are really happy with what they are doing and they are proud of it, while most Java developers, even the ones who are actually contributing much to community more feel that they are doing it as part of their job. Even if they are passionate, there is something different there.
Right now I am really happy where I am. JRuby is really important, but it's not end all programming environment and I really have this hope that I will see Lisp come back again in full force and I would love to be a part of that if I could. I don't really have the time right now to do everything I would love to do, but I have a few ideas I would like to do and I think that the combination of a language like Ruby on a platform like Java and combining that with some of the powerful features of Lisp would be really interesting. If I could, if I had the time at some point in the future I would love to be able to sit down and just mess around with different language features, try to build on what Ruby has done and build Ruby into the next generation language something that is actually even better than Ruby. I am not sure how that should look right now, but I know there are things that could be better in Ruby. It's going to be interesting to see how Ruby 2.0 is. That's going to be fun, but I still think there are things that could be better.