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.

RubyConf 2007: JRuby: Ruby for the JVM

Charles Nutter and Thomas Enebo. They are working at Sun as full-time JRuby developers. Also, they are working on dynamic language support, in general, for the JVM.

What is it? Not just Ruby for the JVM. Ooh, looks like they are going to go in-depth.

Two days ago 1.0.2 was released. Last night 1.1b1 was released, during the town hall discussion.

Topics of discussion: Basics, Lexer and Parser, Design (Core Classes, Interpreter, Compiler, Performance Optimizations, Threading, Extensions and POSIX, Java Integration)

Hand-written lexer. LALR parser, Jay, a Bison for Java. DefaultRubyParser.y => DefaultRubyParser.java. Abstract syntax Tree similar to MRI's.

For demos, they arere using NetBeans. All the completion and formatting is based off of the parse tree.

For now, eval'ed code is always interpreted.

New in JRuby 1.1, there is full bytecode compilation.

There is a demo of the JRuby compiler, showing speed differences between interpreted and compiled mode.

ObjectSpace optimization. each_object is difficult to support on modern VMs. Have to save a weak reference to every object created during execution. Sucks two to five times as much as running normal code. Only real use is in TestUnit, where it looks for all TestCase classes. Someone from the audience asks what about the profilers and memory tools out there? Yes, but those are narrow in scope (Ruby only). Limited control over GC.

Another optimization is custom core classes. Yet another is with regexes. Ola Bini ported MRI's regex engine. There is also Joni, Java port of Oniguruma. It is in progress, but could be the holy grail. It will grow the size of JRuby ~25%, so it is a big project.

JRuby supports only native OS threads. They are heavier than MRI's green threads, but are truly parallel. In 1.1, there will be pooling of OS threads, to minimize spin-up time.

Do you support C extensions? No. Maybe in the future, but the Ruby API exposes too much. Native libraries are accesible with Java Native Access (JNA). It is used for POSIC functions not in Java, like file access.

Java Integration: Popular Use Case: Swing GUIs. Ruby magic simplifies most of the icky/tricky bits. Java is too verbose. No consistent cross-platform Ruby GUI. There are a few ways of going about doing this: direct (Charles' standard demo), cheri (builder approach; dsl), profligacy (targeted fixes; Zed Shaw), MonkeyBars (tool-friendly).

Other big domain is web applications. JRuby on Rails. ActiveRecord-JDBC. GoldSpike/Warbler for app server deployment. GlassFish gem for Mongrel-like deployment.

Upcoming: ActiveHibernate, Ruvlets (Ruby Servlets).

Another use case is Test and Behavior Driven Development. Test Driven Development is hard in Java. RSpec makes it easier.