Saturday, March 31, 2007

ActiveRecord 100%, Performance Doubling, Java Support Improving

I haven't blogged a solid JRuby update recently...and this one isn't going to be as solid as I'd like, but it should let you all know that the wheels are still moving and the train is picking up speed. It's astounding how much progress is being made.

ActiveRecord Now Fully Supported

It's good to have such incredible community members and great core team members.

Ola Bini, who recently accepted an offer from ThoughtWorks, has been hitting Rails unit tests hard. And the module with the most failures has always been ActiveRecord. It's the most complicated and the weakest point in the JRuby on Rails story.

Until now.

1031 tests, 3839 assertions, 0 failures, 0 errors
That headline should read "ActiveRecord Fully Supported on JRuby", for you press affiliates out there.

Of course there's a few caveats, but they're pretty minor in this case. That's zero failures and zero errors when running against MySQL, but it's certainly a de-facto standard in the Rails world. The next step is to get as many other databases to 0/0 as possible. And those are much smaller steps than this first one.

So what does this mean for JRuby on Rails users? Well in general, it means that the heart of your DB-driven JRoR apps--ActiveRecord--is now the best-supported piece of the puzzle. It also means that overall Rails support is well into the 99% range and still climbing.

Performance Continuing to Improve

In addition to the focus on getting Rails working well (which is really a focus on improving overall Ruby compatibility) we've been hitting performance much harder the past couple weeks. I especially have been splitting my time between interpreter and compiler work. As a result of all our efforts, the current trunk code is almost another 2X the performance of 0.9.8, released less than a month ago. The compiler also supports almost 2X the number of syntactic constructs it did in 0.9.8, and it's getting faster and more stable every day.

There are actually a number of benchmarks running faster than MRI (the C version of Ruby) even when interpreted, showing that we're finally making good on our promise to have interpreted JRuby run as fast as MRI. So it truly does seem that the compiler will be "bonus" performance once we work out the remaining bottlenecks in the system.

Java Support Looking and Feeling Better

There have been two areas of focus for Java support the past few months: rounding out features and syntax and improving performance. Both had some great jumps in JRuby 0.9.8, with a couple small fixes improving performance many times and with concrete/abstract class extension finally making it into a release.

Since 0.9.8 we've continued to make progress on both fronts. I've made a few additional small changes to improve overall performance, and Ola's been moving some especially critical pieces of code into Java, since they represented a lot of back-and-forth across that barrier. Where calling into Java code was previously as bad as twenty times slower than calling Ruby code, it's now a modest two times slower. We expect to improve that further, getting as close to Ruby invocation speed as possible.

We've also just added what should hopefully be the final revision to our various "import" syntaxes. Oddly enough, we've come full circle to "import":

# create a new constant "System" pointing at it
import java.lang.System

# use Java::syntax for less-common packages
import Java::my.weird.package.MyClass
And we're considering some improvements to how multiple classes are imported and how to specify an alternate constant name (for classes like String, which would be a bad idea to overwrite).

You can expect to see this all solidifying as we run these last miles toward JRuby 1.0.

--

I will blog more on all this as we get into April, but it's truly shaping up to be Springtime for JRuby in JavaLand.

10 comments:

Daniel Spiewak said...

Honestly, I really like:

System = java.lang.System

...much better than "import". I think it's a lot cleaner. The new syntax you described seems like a step backwards.

The only area in which the current syntax fails is with multiple classes, but it could easily be extended like this:

Lang = java.lang.*
Lang::System # <= java.lang.System

If you ask me, this is a *lot* cleaner than the import syntax.

Daniel Spiewak said...

Oh, great news on the performance improvements. Keep up the good work!

Charles Oliver Nutter said...

Daniel: You're entitled to your opinion! Luckily, in this case there's no reason both can't co-exist comfortably. Remember we're kinda straddling worlds here, and when Java developers find the System = java.lang.System syntax, it immediately feels foreign. The import syntax is a nice shortcut for it, and for whatever reason it seems more pleasing to my eye (probably because I'm back and forth between Java and Ruby all day).

But here's a couple other reasons why I like it:

1. DRY. System = java.lang.System requires me to type System twice. If the name of the class is longer, this is even more painful.
2. Familiarity. It's identical to an import statement from Java, with option semicolon. That's a huge win for drawing in Java devs.
3. Zero impact. Adding this import shortcut doesn't add any overhead or break your preferred syntax, since it builds upon it.
4. It's HELLA better than include_class "java.lang.System"...but to get rid of that syntax once and for all we need something analogous. I think this is a much better version.

Anonymous said...

That's great news! From my years of J2EE development, Oracle will be a crucial milestone for this project, because of its popularity in enterprise environments.

Michael Neale said...

Awesome work Charles !

I like the import syntax (as its Java people who will use it mainly) and its DRY, as you say.

Anonymous said...

Ola Bini???


Is that a name?

Anonymous said...

When saying "The next step is to get as many other databases to 0/0 as possible", is Oracle on the top of your list ?
In large organisations, Oracle is often a defactor standard and to push Rails & JRuby through the door, it has run Oracle DB on a J2EE Server.
If interested, I can have some Oracle tests run against our DBs... just tell me how to participate.

Charles Oliver Nutter said...

romain: No email? :) Yes, we're very interested in getting Oracle 0/0, but it's a matter of having folks to help fight through and report issues. If you're interested in trying to help, hop on the list or on #jruby on freenode and we can help you set up a test rig.

Romain said...

the email slipped through ;-o

for testing, I am currently using netbean 6.0 dev with jruby and trying to practice normal rails dev with it.
If I just do that, is anything I find of interest to you.
what's is the best approach for bug/issue reporting ?
So far, since update 0.2.3, I get the app to read some simple common but I have had to hack around the number type... I think getting the ar<>jbdc type correspondance is paramount to allow testing to progress.

Charles Oliver Nutter said...

Romain: any and all information is of use to us! Ideally you'd sort out whether it's a NB bug or JRuby bug you're seeing at any given time and report in the correct trackers, but either way would get routed to the right folks.

You might also try using the trunk code for ActiveRecord-JDBC. I know the decimal issue you mention has been corrected for Oracle, so you may have better luck. If you need help with that pop on the JRuby or JRuby-Extras mailing lists, or on #jruby on freenode.