JRuby at Thoughtworks - BOF-4807

DISCLAIMER:
These are the tidied up notes I took from the session at the JavaOne 2008 conference in San Francisco, California. There may well be mistakes and ommissions. I will come back and correct them once the conference has completed. However my first priority is to get the information published before the backlog gets too large and swamps me. All comments welcome. Enjoy!

Ola Bini, Thoughtworks
Update: The slides are availble.

Alternative title: "Why Thoughtworks thinks (J)Ruby is worth investing in"

Thoughtworks - 40% of US Revenue comes from Ruby and Rails (more Ruby developers than any other company he knows of), deep involvement in Open Source, source of Selenium and Cruise Control

Product Development
- Mingle
- Cruise (re write of CC)
- Twist - new functional testing framework for Eclipse.

RubyWorks
- CruiseControl.rb (used on Rails project
- Ruby Production Stack (Like LAMP for Rails, plus takes care of security updates)
- JRuby - sponsors Ola's work on JRuby as a core developer

Why Ruby?
- RoR emphasises Agile practices
- Higher productivity
- drastically quicker time to market
- Extremely readable code (reading code is more important than writing it - read 100 times)
- State of the art testing libraries
- Well suited for prototyping
- Easy to implement DSLs (Martin Fowler is writing a book on it at the moment)

Problems With Ruby 0 Threading
- Ruby 1.8 - Green Threading
- Can't scale across processors / cores
- C libs can't / wont yield to ruby code
- 1.9: native, non parallel threads
- lots of work to ensure thread safety

Unicode Support:
- 1.8 Partial unicide
- Internet connected apps must have solid unicide
- App developers must roll their own: Rails Multibyte

- 1.9 Full unicode by drastic unicode
- String interface changes to per-char, not -per-byte
- Not backwards compatibile

Performance:
- 1.8 slower than most languages

- 1.9 improvement but still more to do
- New engine abiout 1.5 improvement
- inly implicit AOT ciompilation to bytecode
- more to do

Memory:
- 1.8 - simple design
- Good for many apps, but not scalable
- stop-the-world GC
- 1.9 no change
- Improved perf => more change

C-entenxsions:
- C is difficult to write well
- but there are many C extensions
- Beware! Badly behaved extensions can cause large problems

Politics:
- needs software, servers and training
- Legacy - lots of java apps in the world and extensive amount of Java frameworks

How JRuby solves them:
- Threading - Java threads are ruby threads. World class scheduler
- Unicide - JRuby uses Java Unicode
- Perf - AOT and JIT cimpoiler
- Memory - java provides world class GC
- Extensions - JRuby extensions are written in Java
- Credibility from running on JVM - knowing JRuby is there makes some Ruby projects OK to some customers

Typical Thoughtworks clients:
- Oracle (mix.oracle.com)
- LinkedIn
- Cisco
- Rackspace

Finaicial Institutions - banks, investment banks, caterpillar finaicial services
Other - SKF, Siemens

Thoughtworls Ruby Work:
- Web 2.0 apps
- internal prototypes
- small to medium web based apps / utilities
- "Soft layer APIs"
- Build systems for complex enterprise systems

Why JRuby?:
- Gives access to all java enterprise features
- conservative environments wqill not use MRO
- Quick integration witrh legacy systems
- Cost: Java+Ruby is more cost effective than MRI (using JRuby you get all good Ruby but with fallback to Java if you have a bottlekneck, legacy java libs, etc)

Case Study - Oracle mix:
- Social networking
- All oracle customers can connect
- Based on internal app (regular rails app) but now JRuby to run on ORacle stack (LDAP, SSL, DB, Linus etc)
- 4 person team (1 oracle) in 6 weeks
- JRuby on Rails

CS - Finance Client 1:
- IS standardised on java
- Glue app to improve integration
- Uses UnitRecord plugin to speed up test suites
- lack of good RMagik replacement has been hard (incomplete versions for JRuby)

Finance Client 2:
- Seperate business units
- aim to consolidate all accoutns, customer info in one place
- Ruby with small java
- 2 persons, 4 months (3 times linger in java)
- interacting with 5 disparate datastores

Why Ruby?
- "those infrastructure guys are just seeing a really large java app with a really large config file"
- Higher business va;lue for lower cost
- Using java apis (esp. JDBC) allowed quicker dev. since no need to write new functionality to Ruby

Case Study: Mingle:
- Agile in an easier way
- around almost a year
- chose JRuby due to lack of good SVN plugin
- Test suite (2.2 tests to code) slower in JRuby (due to lots of shallow func which test lots of pieces of an app. this pattern means the JIT compiler doesn't get any piurchase and most code is just interpreted (which is ~ 1.5 times slower))
- NOTE: Java 7 will move hotspot away frmo java - specific bytecode to more general constructs
- Licences use stong cryptography using a Java RSA library (would have been very hard in MRI but dead easy in JRuby)
- Override JRuby's LoadService which allows us to encrypt/decrypt all ruby files in app/*
- Will probably move to using AOT compilationwhen that is finished
- This is obfuscation - there is no real, safe protection in it
- ...but it seems to work well enough =)
- ChartDirector is a proprietary lib for maing charts
- Have a Java lib and a C extension lib for Ruby
0 A thins wrapper over the Java lib makes it possivle to use the same lib in JRuby and Ruby
- No MRI SVN lib which works on Mac, linux and wiondows
- Initial reason for gong with JRuby
- SVNKit is a java lib which provides SVN access on all java platforms
- install4j - installation and bindles JVM and jetty
- BYO database (used to be Derby - serious load testing broke it)

Mingle Demo:
- 2.0 released a few weeks ago
- Current release burn ups
- Card Wall - everything is a card which has properties
- Feature Trees
- Track bugs
- Where is the project right now
- Clients can also see it
- Because a physical card wall can;t scale outside a single room

Other Projects:
- Swiby (JRuby wrapper over Swing but with also a web and desktop interface)
- Waffle (Java web framework wihch uses JRuby to do controllers)

Challenges:
- Perf of Unit tests
- Solution t0 running MRI precommit ad Jruby in CI or using unitrecord instaed
- startip time (esp of rails) (Staged in background)
- Memory Consuption (high but still lower than mongrel)
- Good replacement for RMagik needed]
- Documentation (but a book is available - Practocal JRuby on Rails)

When to use Ruby?:
- interact wth Java
- you need to be really cross platform
- you are deploying into a Java-based organisation

When not use Ruby?:
- if you depend on unsupported C extenstions
- for smaller scripts
- if you need continuations
- corner cases on POSIX