Archive for the ‘JRuby’ Category

JRuby 1.1.3 has been released a couple of days ago, and I wanted to highlight some of the most interesting changes in this release, from my perspective.

1. RubyGems 1.2. If you ever installed even a single Ruby gem, you know the blues, it was taking way too long, consuming lots of memory and felt pretty heavyweight. In the past, we even had to increase the memory limits for JRuby up to 500Mb so that RubyGems could work without out of memory errors. Not anymore! RubyGems 1.2 is a fantastic release that speed things up dramatically, and JRuby 1.1.3 comes with it by default. Just try it and you’ll be amazed, I promise! Not only that, but RubyGems 1.2 is much easier to customize to suit the needs of particular implementations/platforms, and we’ve taken full advantage of that, eliminating essentially all custom JRuby-specific patches over the RubyGems sources. All in all, kudos to RubyGems team!
2. Performance. Some of us are obviously obsessed with performance, so there was a lot of work put into that area, yielding out nice results. And the first measurements are pretty encouraging. Here are some of the things that were improved in this release:
   • Interpreter performance is greatly improved (Tom landed a couple of nice bombs on that one!)
   • Core IO performance and memory requirements significantly improved, memory leaks in IO eliminated.
   • Time’s methods are much faster now.
   • Some loops and block invocations improvements. Things like 10000.times {} are faster now.
   • General performance fixes to use faster methods where possible, JIT tweaks, reduced object churn.
   • Memory leaks in RubyArray are fixed.
3. Compatibility/Conformance. There were *LOADS* or compatibility test fixes, most of them were driven by RubySpec tests and test failures. For StringIO alone, we had fixed at least 50 failures. Then, lots of fixes for Socket, ARGF, IO, Kernel.select, for problems with various empty expressions, etc. I tell you, if you feel serious about some important functionality in Ruby and want it to be properly tested and consistent across ever-growing list of Ruby implementations, there is no other good way but to join the RubySpec revolution!
4. Usability. New command line options like --server or --client instead of -J-server or -J-client, also --debug and --jdb now functional on Windows. Better out of memory error messages. Some 1.8.7-level improvements, like better Tempfile (with ability to specify the suffix/prefix for the file). Also, some classloader fixes so that JRuby could work better with 3rd party libraries like Spring, XMLDecoder, Activerecord-JDBC drivers shipped via RubyGems, JXTable, etc, would work without clunky workaround (see JRUBY-2495 for more details).

I think, that’s quite enough for 1.5 month work… Enjoy!

While I was at it with making a full git clone of Matz Ruby repository I also created a full clone of JRuby subversion repository and posted it on my GitHub account for your enjoyment:

Full Git Clone of JRuby Subversion Repository.

This repository has all the tags and most branches. As with Matz Ruby repo, it is being updated hourly. Personally, I find Git much more convenient to work with, especially when I don’t have commit rights to the repository, but still can make local patch queues and local branches. See my earlier entry on the topic: “Using Git for Ruby/JRuby development“.

I’ve been wanting to have a full git clone of Matz Ruby Subversion repository for a while. In fact, I’ve been using a private git clone for a few months already, and really like the speed of switching between branches and immediate history search. This all gets really handy with current explosion of different versions of Ruby (1.8.5, 1.8.6 with more than 200 patch-levels, 1.8.7, 1.8-dev, 1.9). Using all these different versions is essential when writing the new RubySpec tests.

And since now more folks than ever are writing the RubySpecs, dealing with Subversion gets painful for many, and the public Git repository of Matz Ruby is going to address that. So here it is:

Full Git Clone of Matz Ruby Subversion Repository.

For more info on how to use, take a look at the README. In a nutshell, just clone the repository, create local tracking branches for those remote branches that of interest to you, and keep updating your repository periodically.

And for those who’d like to know the steps in order to repeat them on other Subversion repositories, read on.

First, I fully cloned the entire Matz Ruby Subversion repo, using git svn:

   1: git svn clone –stdlayout http://svn.ruby-lang.org/repos/ruby

Then, I created an empty git repository on GitHub. So far, pretty standard procedure. The only tricky part was to figure out how to push remote branches from my freshly svn-cloned repository to public branches in GitHub’s repository. Without this, it would be pretty complicated to keep all the branches updated (you’d need to create local branches, update them manually, one by one, and then push them).

Luckily, git’s flexibility allows to do all kinds of interesting things, sot it was easy to write some config entries to “re-wire” remote branches in local repository to public branches in  the GitHub’s one, I had to adjust the .git/config file:

   1: [remote "origin"]

   2:    url = git@github.com:vvs/ruby-mirror.git

   3:    push = refs/remotes/trunk:refs/heads/trunk

   4:    push = refs/remotes/ruby_1_8:refs/heads/ruby_1_8

   5:    push = refs/remotes/ruby_1_8_7:refs/heads/ruby_1_8_7

   6:    push = refs/remotes/ruby_1_8_6:refs/heads/ruby_1_8_6

   7:    push = refs/remotes/ruby_1_8_5:refs/heads/ruby_1_8_5

   8:    push = refs/remotes/ruby_1_6:refs/heads/ruby_1_6

   9:    push = refs/remotes/ruby_1_4:refs/heads/ruby_1_4

  10:    push = refs/remotes/ruby_1_3:refs/heads/ruby_1_3

  11:    push = refs/remotes/tags/*:refs/tags/*

With that change, every push to the “origin” repository (the GitHub one) will push remote branches in my private repository to the public branches of GitHub repository.

Finally, the process to keep the repository up-to-date is now straightforward:

   1: git svn fetch –all # fetches ALL branches from svn repo

   2: git push            # pushes all branches to public git repo

Update: The repository has been moved from my personal GitHub account to the RubySpec GitHub account, to compliment the currently existing RubySpec and Mspec repositories there.

Note #2: Nick Sieger has a JRuby’s git clone (only for the main trunk though): http://github.com/nicksieger/jruby

NetBeans 6.1 has been released recently, and the upgrade was easy and pain-free for me. I haven’t found any serious problems so far and the release looks very solid and performant. The Java stuff works just fine, and Ruby capabilities are great. For those who look for a great and intelligent Ruby editor, NetBeans is one of the great candidates.

One minor issue with NetBeans 6.1 is that it ships by default with very basic IRB console for Ruby: no history, no pop-ups for code completion. Since I’m used to JRuby IRB Console which provides those advanced features, that was a bit of inconvenience for me.

One of NetBeans guys, Martin Krauskopf is to the rescue! It turned out that there is a special property that enables the full JRuby IRB Console. Just add

   1: -J-Dirb.jruby=true

to the netbeans_default_options entry in the etc/netbeans.conf file. A word of caution though: The JIRB Console was disabled by default due to some problems it was causing in some environments. For me, on Windows, it works just great.

Currently, there are at least FIVE actively developed Ruby implementations out there in the wild. For an excellent overview of the current state of affairs take a look at the Charles’ article: “Promise and Peril for Alternative Ruby Impls”. Having that many implementations, despite all the good things, also brings a new set of challenges. One of the biggest challenges is the compatibility. Some are even starting to say “balkanization” word. (You know who you are!)

That’s where RubySpecs come in. The great promise of the RubySpecs is to provide a unified compatibility and conformance test suite, universally used by all Ruby implementations. The Ruby implementers are not only going to use the tests, but also contribute back the new specs, increasing the value and the quality of the test suite over time. At the moment, we know that Rubinius folks (who started the whole RubySpec thing) actively use them on a daily basis, with a couple of continuous integration bots, and using the RubySpecs as a driver to implement new features in a test-driven approach. Brian Ford is doing an outstanding job supporting the mspec (the engine behind the specs) and accommodating users requests for new features and enhancements. JRuby uses the RubySpecs equally actively, running them on MacOS, Linux and partially on Windows. All the new tests that are of compatibility/conformance nature typically go directly to the RubySpec repository. IronRuby uses the RubySpecs too. Hopefully, we’ll see some contributions from them too, that would be really sweet! And last, but not least, during the first “Design Meeting” with ruby-core folks (including Matz), the RubySpec question was raised, and it seems that even Matz Ruby folks would start looking into it, and eventually using it.

So, if all goes well, most of the current active Ruby implementers would be using the common set of conformance tests. The RubySpecs are going to be forked off from the Rubinius repository and would live in the proper place as a main project on its own, with a bug tracker, a web site, etc. Also, some more folks would start working on the specs via Google’s Summer of Code program. Very exciting!

As an example, take a look at the BigDecimal support. At the beginning of April, there were no specs for BigDecimal. JRuby had a skeleton implementation, missing some methods or just having stubs for some other methods. Rubinius had no BigDecimal support altogether. Three weeks and 43 commits later (by the way, five different folks contributed to the tests), there are 1772 test cases for BigDecimal in the RubySpecs, JRuby has already fixed hundreds of failures, now passing most of them (with 6 remaining tests to be fixed soon) and Rubinius has a actively improving BigDecimal support too.

I guess, the main thing I’m trying to say here is that now it’s the perfect time to look into the RubySpecs and to start contributing. That way, you’ll affect ALL the Ruby implementation, making ALL of them better! For more info, take a look here and here.

This was always confusing me, since Ruby has many ways to perform the division. So, here’s a fresh quote by Matz himself:

We have /, div, fdiv, and quo:
  /     - normal division, according to the class of operands
div    - integer division
fdiv   - float division
quo   - most accurate division (float if either operand is float, otherwise rational)
rdiv   - (which always results in rational) is obsolete.

So, you have that new and shiny JRuby 1.1 and would like to try it out with rails. Here’s a quickest guide to do so! The guide assumes that you want to use MySQL as the database, and it has already been installed.

First, install the following gems:

• mongrel - simple but powerful web server.
• activerecord-jdbcmysql-adapter - all you need for activerecord on JRuby to talk to MySQL.
• rails - well, the Ruby on Rails proper.

The command line:

   1: jruby -S gem install mongrel activerecord-jdbcmysql-adapter rails

Create a sample rails application with MySQL backend:

   1: jruby -S rails myapp -d mysql

Enter the newly-created “myapp” directory, then modify the config/database.yml. First and foremost, you need to adjust the adapter name, and instead of ‘mysql’ you should specify ‘jdbcmysql’. You might also want to delete the lines starting with “socket:”.

Here’s a simple example for the development environment:

   1: development:

   2:   adapter: jdbcmysql

   3:   encoding: utf8

   4:   database: myapp_development

   5:   username: root

   6:   password:

Now, it’s time to create our database:

   1: jruby -S rake db:create:all

The next step is to create some minimal scaffolding so that you could actually play with some dynamic functionality and database access:

   1: jruby script/generate scaffold post title:string body:text published:boolean

We need to update the database after that:

   1: jruby -S rake db:migrate

And we’re basically done here, just start rails via:

   1: jruby script/server

and point your browser to the:

   1: http://localhost:3000/posts

Enjoy!

This is a quick guide for those, who’d like to run the Rubyspecs with minimal effort. For those who have JRuby repository checked out, the steps are even easier: ‘ant spec’ - and you’ll run all the unexcluded specs against the freshly built JRuby.

1. Pull the Rubinius repository (and you have to have git for that):

      1: git clone git://git.rubini.us/code rbx

2. Alternatively, you could just download the snapshot of the repository in a compressed file. (Look for “snapshot” links at the page).
3. Basically, that’s it for the setup. Now, just run the tests:

      1: cd rbx  # Step into the directory you’ve created when pulled

      2: bin/mspec -t ruby spec/ruby/1.8 # Run all Ruby 1.8 specs

      3: bin/mspec -t ruby spec/ruby/1.8/core/kernel # Run Kernel specs

      4: bin/mspec -f s -t ruby spec/ruby/1.8 # More verbose output

4. During the execution, the dots will be printed out, and the final summary, but with “-f s” option, the output is much more interesting:

      1: Kernel.proc

      2: - returns a Proc

      3: - raises an ArgumentError when no block given

      4: - raises an ArgumentError when given too many arguments

      5: - returns from block into caller block

So, that’s about it. The rubyspec format is compatible with Rspec, so there should be no major surprises there. More info *is* available at the official page. I’d suggest to start with “Specs - Overview” and explore from there.

The long awaited JRuby 1.1 is finally out. Working on it was fun, much more fun than I expected — so much to do, so many interesting things, so little time! It is a perfect mixture of Java and Ruby, actually improving my skills in both areas.

For me, it all started last Fall, after a couple of very convincing blog posts by Charlie: How Easy Is It To Contribute To JRuby? and Easy JRuby 1.0.2 Bugs. So I started playing with JRuby, looking for things I could fix, and it turned out that the easiest way to get involved is to look at the Rubyspecs and try to pass as many of them on JRuby as possible. I’ve started filing bugs and submitting patches, and eventually become a JRuby core comitter.

And since then, my main focus is on the compatibility with Ruby, on tests and especially the Rubyspecs. Having spent about 10 years in Java SE and Java ME compatibility, it was rather natural choice for me. We now have the rubyspecs nicely integrated into JRuby build, we maintain an exclude list for those specs that currently fail (and for every new failure we have the bug filed), we sync-up with the main rubyspecs repository frequently and contribute new specs back.

Some major things to do in the future: set up the continuous integration runs for rubyspecs, make the rubyspec runs on Windows and fix the specs to work properly on Windows. It is expected that much more effort will be put into Java Integration infrastructure, and we’ll need an extensive set of tests/specs for the area. The barriers to entry are very low now, and it’s very easy to contribute, so consider doing so!

Some random stats: So far, I’ve filed 232 bug reports, fixed 112 bugs and made 195 commits.

On to JRuby 1.1.1!

It was a “JVM performance week” in JRuby-land. It all started when some recent code changes is JRuby caused an interesting performance degradation with JDK6 on multi-core CPUs. See the original post to the [jvm-l] list and extended coverage of what happened on Charlie’s blog. So, while following the discussion and participating, I learned a few new things and got some interesting additional info and links that I’d like to share:

1. Let’s start with basics. John Rose posted a good starting guide for those who’d like to micro-benchmark things on JVM: So You Want to Write a Micro-Benchmark.
2. Performance techniques used in the Hotspot JVM wiki entry with the list of optimizations JVM does, sweet and to the point.
3. Fundamental work by Ulrich Drepper: What Every Programmer Should Know About Memory, a MUST read, but painful
4. Deep dive into assembly code from Java blog post by Kohsuke Kawaguchi, on how to print out the assembly code that JIT is producing.
5. Examining generated code with OpenJDK 7, exciting stuff!
6. Polymorphism Performance Mysteries Explained, the Issue #158 of The Java Specialists’ Newsletter.
7. How fast is Java Volatile? or Atomic? or Synchronized?, with nice charts and comparisons.
8. Escape analysis can help optimize synchronization by Brian Goetz.

Enjoy!