Sunday, November 4, 2007

RubyConf 2007: JRuby in the Wild

Kyle Maxwell works at CastTV

Video Search is hard.

$ jirb -rjava
> import java.util.TreeMap
> map = TreeMap.new
> map[1] = 4
> map[2] = 7
> map.inject(0){|memo, (key,value)|
> memo += key + value
> }
# 14


Why use it? Yet another war (deployment). Familiar tools (java).

JRuby is not perfect. Use the right tool for the right job. There are organizational (are you already a java shop?) and situational concerns.

Ruby is missing a few things in its current incarnation: performance and library support. There is some room for improvement, but not by us. You can make the choice of moving things down to the C-level. Want to solve the problem in the highest-level language possible. Java.

Choices I've made:
  • Rails (sticking to MRI, for now)
    • possible performance issues
    • regex library
    • already working in CRuby
    • experience with standard deployment
  • Search (JRuby/Java)
    • Decided to take an open source search engine and build heavily upon that
    • initially tried MRI/ferret (extending the C was a nightmare)
    • then tried CRuby/Solr (didn't want the extra overhead of another java server and concerns about maintainability)
    • finally Lucene/JRuby (easy to maintain; clear method of extension; less to break; JRuby is an active project)
  • Spellchecker (JRuby/Java)
    • performance is at a premium (look at the performance of your algorithms before you look at the performance of your language)
    • ternary search trie algorithm
    • tried it in ruby first (creating a million nodes takes ten seconds; also, there was a large memory overhead)
    • same reasons as above for skipping C
    • java (tried to do inline java and it was too painful; access java objects from ruby)
port, api, or binding?
  • never port anything (most overheard and is error prone)
  • api has the overhead of building the needed layers
  • binding had least overhead
an off-the-cuff benchmark (load the unix dictionary into a hash, ten times)
  • MRI 12.9s and 144MB
  • JRuby (with J-server) on the Sun 1.5 JVM 9.0s and 72MB
  • Java 1.5 4.1s and 61MB
  • Perl 4.1s and 19MB
getting started
  • easy install (personally, works off of trunk)
  • jruby -S [gem, rake, ...]
    • unless it is a gem that requires a C extension, it will work (hpricot was ported)
  • get the extras
  • textmate not advised (personally, works in eclipse)
  • a sane build strategy
  • jar2gem.rb
gotchas
  • casting can be tricky (e.g. float, arrays (see to_java))
require "java"
A.new 1.99 # will be passed as a double and won't cast
A.new java.lang.Float.new(1.99) # works


Is there anything you wanted to do in JRuby, but couldn't? Yes, and this will hopefully be fixed. Interacting with POSIX operating systems (file permissions, etc).

Have you evaluated Groovy? No.

We're running all our JRuby processes as standalone daemons.

Man, I really need to work on my public speaking skills. I sputtered through asking my question to Kyle.

Have you dealt with JRuby in the context of a legacy (non-greenfield) Java System? Any problems there? No. Someone from the audience brings up the issue of the production staff only dealing with java deployments. I have a feeling that there have to be issues, just no one here has run into them. Related to this is that there don't seem to be many language agnostic people here.

No comments: