• Homepage: http://www.jruby.org/
• Download: http://www.jruby.org/download

The primary goal of the 1.6.x series is to round out our 1.9 support by fixing any reported incompatibilities. Of course, as with any JRuby release, we will continue fixing any found incompatibilities and also improve performance. All users of 1.6.5.1 (and lower) are encouraged to upgrade to 1.6.6.

Because master keeps getting further and further away from our 1.6 branch we have decided to make this our last 1.6 release. We largely fulfilled our goal of having reasonable 1.9 support. Follow up fixes for 1.9 support will only be fixed on master from this point forward. JRuby 1.7.0 will be the next release of JRuby.

Notable Changes:

• Updated stdlib to match Ruby 1.8.7p357 and 1.9.2p312
• Updated RubyGems to 1.8.15
• Multiple 1.9-mode yield/splat bugs fixed (pp, rspec 2.8 working again)
• Multiple 1.9-mode encoding bugs fixed
• Critical fixes in Random and Fiber
• Map Scala operator methods to symbolic names ($plus, etc)

1.6.5 Issues Resolved:

• JRUBY-6386 time.localtime not taking any arguments
• JRUBY-6384 yaml broken for last 1.6.6 build?
• JRUBY-6383 Scala integration breaks with 1.6.6
• JRUBY-6382 1.9: Padrino can’t generate an app
• JRUBY-6381 java.util.Collection#each dose not respect to_ary defined by objects that are iteratered
• JRUBY-6380 Original array is overwritten when select! is called on a copy
• JRUBY-6377 rspec .should include() fails in –1.9 mode
• JRUBY-6375 Uninformative YAML parser error
• JRUBY-6373 ThreadError: Mutex is not owned by calling thread, when interrupting thread using a Ruby Mutex
• JRUBY-6370 Regression in 1.6.6 in –1.9 mode
• JRUBY-6367 –pre command line switch not working in 1.9 runtime
• JRUBY-6366 More array splatting bugs in 1.9 mode
• JRUBY-6361 RbConfig reports wrong OS type on Solaris
• JRUBY-6359 Can’t convert nil to String building ActiveSupport RDoc in 1.9 mode
• JRUBY-6354 SyntaxError: (RegexpError) invalid multibyte escape in 1.9 mode in the 50th iteration
• JRUBY-6338 JRuby does not look for .jrubyrc in home directory on Windows
• JRUBY-6324 random seed for srand is not initialized properly
• JRUBY-6323 JRuby does not pay attention to either -U or LANG in determining encoding for ARGV (it is always ASCII-8BIT)
• JRUBY-6319 ‘binding’ returns wrong binding
• JRUBY-6318 Tempfile#open does not return the value of the block given to it
• JRUBY-6307 Powering operation of Integer sometimes gets a wrong calculation when 1.9 mode.
• JRUBY-6303 Cannot gem install from a remote repository in 1.9 mode
• JRUBY-6295 Dir.chdir, $HOME and $LOGDIR behavior
• JRUBY-6284 Calls to Kernel#exit result in an exception printed on stderr
• JRUBY-6282 Colon is not allowed in a file name on Windows
• JRUBY-6281 1.9: Applet does not work in the 1.9 mode
• JRUBY-6272 Encoding exception running JRuby 1.6.5 (1.8 mode)
• JRUBY-6233 jruby-complete-1.6.5.jar!/META-INF/jruby.home/bin/rake missing
• JRUBY-6227 1.9: Struct#members and Struct::members should return an Array of Symbols in 1.9
• JRUBY-6224 In MRI 1.9 the flag for Module#const_get also controls lookup of toplevel constants but not in JRuby
• JRUBY-6217 Coverage module not working with Rails ActiveRecord associations
• JRUBY-6214 Dir#rmdir raises improper exception if directory is not empty.
• JRUBY-6212 IO#inspect in 1.9 could be prettier
• JRUBY-6209 Hash#rehash does not work under some condition
• JRUBY-6208 bad gem file creation using mode –1.9
• JRUBY-6206 Incorrect SHA1 on two required packages in Maven Central
• JRUBY-6205 ‘Bad file descriptor’ when using IO.popen4 with OpenJDK 7
• JRUBY-6204 UTF-8 char in XML hangs in Joni
• JRUBY-6202 JIT-ed class names only use method names, causing collisions
• JRUBY-6201 File reading performance regression
• JRUBY-6200 1.9: Loading some Unicode characters results in non-printable characters on Windows
• JRUBY-6199 JRuby is hardcoded to use ‘-mmacos-version-min=10.4’ which is not compatible with ‘-rpath’ being used
• JRUBY-6198 When calling dup on file open in binmode the new object does not respect binmode
• JRUBY-6192 jruby::Handle declarations use ‘extern “C”’, causing linker symbol mismatches
• JRUBY-6182 Marshal.dump yields different value after adding/removing instance variables (and disagrees with MRI)
• JRUBY-6176 SecureRandom.uuid is not implemented
• JRUBY-6173 pp is broken in –1.9 mode
• JRUBY-6172 Requiring a file from a JAR that has a path inside the JAR that coincides with a path on the file system that includes a symlink fails
• JRUBY-6171 Enumerable does not splat
• JRUBY-6170 Fibers are broken in JRuby 1.6.5

1. JRuby 1.6.5.1 is a single patch release of JRuby 1.6.5 to fix CERT advisory: CERT-2011-003.  ALL USERS: PLEASE UPGRADE
2. We talk about plans for the upcoming 1.6.6 release

CERT Details

Hashing 101

(For proper CSci vocabulary and a lot of fun details about hashing also read this wikipedia article)

Hash tables apply a math function (hashing function) to the key of a key-value pair. The result of the hashing function is a location to a hash bucket which stores the key/value pair internally:

a[:heh] = 1
hashing_function(:heh) -> store :heh/1 in hash bucket #3
a[:foo] = 2
hashing_function(:foo) -> store :foo/2 in hash bucket #13
a[:bar] = 3
hashing_function(:bar) -> store :bar/3 in hash bucket #1

Hashes have many buckets and in theory all key/value pairs added to a hash will get spread out evenly across the hashes buckets.  In practice, some number of keys will end up hashing into the same hash bucket (known as a hashing collision).  As you get more key/value pairs stored to the same hash bucket the time to access those particular key/value pairs will slow down.  This is because you need to walk some portion of the entries in the bucket to find the specific one you are looking for (hash structures will often make entries in an individual bucket a simple list structure).

a[:gar] = 4
hashing_function(:gar) -> store gar/4 in hash bucket #3 (same bucket as :heh)

In this example, accessing a[:gar] and a[:heh] may take longer than the other keys because they are sharing a hash bucket.

The Attack

The general application of the attack is for "the bad guys" to figure out a large set of values which will hash to the same hash bucket.  Once they create this list they will send all those values to a server.  The server will store them in a hash (think parameter list in Rack, for example).  The act of storing or accessing any of those values takes longer and longer as the number of entries in a single hash bucket grows.  The result will be a Denial Of Service (DOS) attack if enough values get stored.

hashing_function(:hostname) -> hash bucket #3
hashing_function(:aZ1) -> hash bucket #3
hashing_function(:cvg) -> hash bucket #3
hashing_function(:azr) -> hash bucket #3
... # many elided
hashing_function(:1fr) -> hash bucket #3
hashing_function(:yu3) -> hash bucket #3
hashing_function(:hyX) -> hash bucket #3

host = params[:hostname] # Uh oh! need to find this amongst many bucket buddies

The Fix

Adding a little bit of randomization to the hashing algorithm ends up making it much, much more difficult to figure out how to generate this type of attack.  JRuby 1.6.5.1 (and all later JRuby releases) all have this additional randomization built into the hashing algorithm.  The result should be decent hash bucket distribution that is difficult for attackers to predict.

More information

This vulnerability is not exclusively an issue of JRuby.  Other Ruby implementations also have a similar issue (also patched today).  In fact, Java and PHP also appear to be susceptible to this style of attack.  For more information, please see the CERT announcement.

Also, consider that language implementations are really only susceptible to this attack via frameworks which allow an external hacker to store arbitrary and/or unbounded key/values into a hash.  Ruby Rack had this vulnerability, but they have fixed things so that the amount of parameters stored is bounded by a size to remove the possibility of a DOS attack.  Rack users should upgrade to the latest version.

JRuby's First Security Fix-Only Release

We debated rolling what we have in our 1.6 branch along with the hashing vulnerability fix (mentioned above) and pushing out 1.6.6.  This was unappealing for a couple of reasons:

1. For stable environments deployed using 1.6.5 we would be asking them to evaluate this security fix and any other fix we placed on JRuby 1.6 branch in the last two months.  This seems like it would force more conservative users to perform their own build to manually patch just the security fix.
2. Of bugs we have fixed so far we felt we were about 10 short of what we wanted to have in JRuby 1.6.6

After consideration, we felt it best to give a security fix release now (A single security patch release JRuby 1.6.5.1 <--- update to this now please) to satisfy the cautious and to wait until we felt good about the quality of 1.6.6.  As they say, Open Source projects are ready when they are ready...

Hey! When will you be ready? What is missing?

It has been about two months since our last release and we suspect we can wrap things up in the next couple of weeks.  We plan on releasing JRuby 1.6.6 in mid-January.

As we have been saying all through the 1.6 series, we are primarily fixing 1.9 compatibility bugs.  Generally speaking, our 1.9 issue fixing has been dominated by encoding errors in Regexps, IO, and String.  Here is a list of what we have done so far.  It is also worth mentioned we fixed the regression which regressed Fiber (JRUBY-6170) in JRuby 1.6.5.  Also the dreaded missing 'read_nonblock' has been fixed (JRUBY-5529).

Here is the list of issues we are plan on settling for 1.6.6.  A few noteworthy mentions in this list is JRUBY-5657 (new 1.9 splat behavior), JRUBY- (new 1.9 to_ary behavior), and JRUBY-6067 (Windows YAML issue).

If there is some issue we don't have targetted but you think is drop-dead important then please let us know...We are willing to expedite other issues if presented with a reasonable case for why it should be fixed.  Please join the discussion.

Ignite RailsConf

Date: Monday, May 16, 2011
Time: 6:00pm
Location: Sheraton Inner Harbor, 300 South Charles St., Baltimore, MD 21201
Expect: awesome 5 minute talks from 15 great speakers

Ignite RailsConf is back again. Snag an Ignite RailsConf ticket to partake in the fun. Dr. Nic will be doing "Ignite Karaoke" a guaranteed 5 minutes of humor as Nic presents slides he's never seen before. Oh, and don't forget to join us for the after-party at Max's Taphouse. Should be a blast.

Ignite After-Party

Date: Monday, May 16, 2011
Time: 9:00pm on
Location: Max's Taphouse, 737 South Broadway, Baltimore, MD 21231
Expect: delicious beer (800+ to choose from) and snacks

JRuby Hackfest at BohConf

Date: Tuesday, May 17, 2011
Time: 1:50pm-5:15pm
Location: BohConf at the Baltimore Convention Center
Bring: questions, code, desire, your laptop
Expect: answers, fun, hacking, beer, and snacks

At RailsConf 2008, in Portland, we had our first JRuby hackfest. Over 100 people showed up and we had a great time. It was cool to see applications leveraging Java technologies. We met new users who wanted to try debug some issues running their applications on JRuby. We also had some folks who wanted to help contribute patches to JRuby. Mix in some some snacks, beer, and great people....OMGZ...the event totally rocked.

It is time for history to repeat.

Rubinius Office Hours

Brian Ford will be on-deck at RailsConf holding Rubinius help desk hours. If you have Rubinius questions, or want to share feedback about your experience with Rubinius, holler at @brixen in Baltimore or swing by the Engine Yard RailsConf booth to find out more Rubinius help desk details.

EventMachine RubyConf

Last but not least, there's also some planning in the works for EventMachine RubyConf, a half day event that will take place during RailsConf. Time, date and location are being worked out and will be announced shortly. Watch @emrubyconf for details.

See you at RailsConf, or another event soon!

• Large number of 1.9 compatibility issues addressed
  • Encoding issues (especially involving Regexp)
  • Fiddle implementation
  • non-ASCII identifiers
• irb (1.8.7, 1.9.2) and command prompt added to Windows installer
• Compiler handles all 1.9 syntax now
• Fixes for new backtrace accuracy, reliability
• Removed all GPL or LGPL-only dependencies
• Updated to RubyGems 1.5.0
• C extension support prebuilt for OS X, Linux (32/64), Windows (32)
• 83 issues resolved since RC1

Now some of you may be thinking...

RC2 had 83 resolved issues?  Are you sure RC are the proper letters for the last two releases?

Hindsight is 20-20.  We knew 1.9 compatibility was not perfect, but during our RC1 release testing we were able to run all the major applications and libraries for a reasonable set of scenarios.   The truly surprising thing we realized after RC1 was released is how many people are ready for 1.9 support in JRuby.   The feedback has been tremendous and we decided it would make sense to spend extra time fixing reported issues.  After all, we want JRuby 1.6.0 to have solid Ruby 1.9.2 support.

Please (or should I say PLEASE) give RC2 a spin and help us figure out if RC2 is good enough to become final.   Only people actively using JRuby’s --1.9 flag can help us figure this out (and of course any 1.8.7 bug reports are also welcome).  Your testing will make the difference between a production-ready 1.6.0 and a production-ready 1.6.1.

If you do find an issue you can report the problem on our issue tracker.  If you are a first-time reporter you will need to signup to be able to create an issue (follow tiny ‘sign up’ link underneath the Username field).

Well Duh!

Micah Martin created a Windows installer for JRuby that made JRuby much easier to install. A new user can double click on the installer, get their PATH configured, install a JVM if they need one, and have a fully functioning Ruby environment in a matter of seconds. We played with it a bit and decided it was cool beans. The rest is history. What we didn't count on was how popular Windows was as a platform. To non-Rubyists this may sound patently stupid, but as Rubyists, we mostly ignore Windows. Much to our surprise, we discovered that the number of Windows installer downloads started to match the number of downloads for our generic tar and zip downloads of JRuby. Cowabunga...people use Windows!?!!?

Seeing so many Windows installer downloads was a "well duh!" moment for us. Ever since that day, we realized that as Rubyists we need to embrace Windows and make sure the Ruby Windows experience is pleasant. I am going to talk about what JRuby is doing to make Windows developers happy, but I wanted to first try and make a rally cry to Rubyists everywhere...Please help make Windows a reasonable development platform choice.

Small Plea to Rubyists

If you have ever been to a Ruby conference and stood at the front of the room you will make one fairly common observation:

Macs Everywhere

In the public Ruby world, a Mac laptop seems like a prerequisite to membership (full-disclosure: I have been using Mac notebooks for 4-5 years). Much to Apple's credit they make very nice laptops. I think the bigger picture is seeing a laptop with 13% of the market share making up 95+% of a Ruby conference indicates a significant problem. If you are a Mac-using fork()-wielding Rubyist why should you care about Windows users?

The most obvious answer to why you should care is market share. There are a tremendous number of businesses which do their day-to-day work on a Windows OS. If these Windows-using companies adopt Ruby then there are more job opportunities for all of us.

A less dog-eat-dog motive is wanting to share something you love. I love using Ruby and I think any programmer, regardless of OS, should have the opportunity to use Ruby.

"Ruby cares" (faint PSA music in the background)

Okay, stepping off the soap box a little...

If you want to help, what can you do? Of course you can start using Windows, but odds are, you bought a Mac to avoid using Windows. ;)

Still, you can do several things:

• Be helpful to anyone who submits a Windows patch to your library/application. Ultimately, little bugs here and there will make or break Ruby adoption on Windows.
• Look for unix-y Ruby commands like fork() and consider alternatives like spoon. We can blame some of the unix-parentage of Ruby for this, but a little effort to make your code portable will make a big difference.
• Of course, some libraries may never run on Windows. In that case, please mention that on your project's homepage. Perhaps even put a hook in your code to throw an error when being loaded from Windows.

require 'rbconfig'
if RbConfig::CONFIG['host_os'] == "mswin32"
    raise LoadError.new "This library does not work on Windows"
end

• Make sure you are using libraries like Pathname which should help isolate you from writing Windows-unfriendly things like:

def absolute?(filename)
    filename =~ /^\//
end

You can instead rely on Pathname to do the right thing for you:

require 'pathname'
Pathname.new("c:/").absolute?  # => true

If you find yourself making assumptions about files or filesystems, odds are your code will not work on Windows.

• Test your library on a continuous integration (CI) server running on Windows (a little more on this below).

What we are doing

We are on a never-ending quest to improve our Windows support for JRuby. Lately, we have been spending some portion of our development week dog-fooding on Windows. This has been a boon for finding issues, and we will continue this practice for the foreseeable future.

Beyond dog-fooding, we have recently set up a CI instance running Windows (a long-desired item for us). We finally have quick feedback when we break something on Windows.

If you are interested in making your gem work on Windows, you can contact us and we will let you run your library on our CI box for a while to get it in shape for Windows. (We would extend the offer forever, but we only have so much processing power.) This can be a valuable experience in understanding some of the issues in making your code more portable. Take us up on the offer.

We also wrote a native version of the windows-specific extension win32ole with funding from Audentes Technologies (thanks guys). For those unfamiliar with win32ole, it is a library which allows you to connect to Windows applications and services and call them progmatically. For example, in a few lines of Ruby you can connect up to MS Word, load a document, and then save it as an HTML document. JRuby 1.6 will bundle win32ole in our windows installer. It is also released as a gem so you can update to the latest and greatest when fixes come out.

As some level of proof we have been working hard on Windows support, a majority of 1.5.x issues resolved have been Windows-related. We are going to keep polishing things until we get it right.

What will we do next?

We wanted to share some of our future Windows plans in the hopes people will have feedback and suggestions. Our next big project on Windows will be to make an 'all-in-one' installer. This installer will contain all the necessary stuff needed for a new Windows developer to go from zero to Rails. We plan on including the following in the new installer:

• JRuby
• JVM
• Redcar editor (sweet Textmate clone)
• Gems: Rails, Rake, RSpec, Rubygems, AR-JDBC
• Simple Rails tutorials
• Links to common Rails/Ruby websites

Our hope is that this will help give a new Windows developer a positive experience. Hitting lots of little roadblocks is no way to get introduced to a new technology.

Let's become a big tent

If you are a Windows person reading this, hopefully you can see that we are trying to make sure you have a top-notch Ruby runtime at your disposal. You can help form our future by giving us feedback on your experience. We really appreciate you giving us a try.

If you are not a Windows person, then hopefully you are on-board with the idea that Ruby should run well on Windows. I believe it is one of our largest potential growth factors, and we have definitely not given an appropriate amount of support on Windows. (Note: There are some heroic souls like Luis Lavena on the Ruby C impl side who are trying -- my hat goes off to them in fighting the good fight).

Let's make 2011 the year we start seeing more Windows laptops at conferences!

Mister Potato Head
(Courtesy of Flickr user MyMollyPop)

Bear with me for a second, and excuse what must have just sounded like a wee bit of lunacy. The the truth is, we live in a world where, as programmers, we construct Mr. Potato Heads every day. We're confronted with making software where not only are we required to stick various elements together, but also to arrange them in the most pleasing way possible.  Software design is really just like decorating a potato. The potato of this blog entry will be build software.

Build Tools

In the Java world, Ant is the 800 pound potato of build tools.  It's in virtually every Java build environment on the planet.  To date, I have only really known one person who really really liked Ant.

For the most part, I think people respect Ant as a tool which is a bit syntactically gross, but which gets the job done reliably.  It is also lamented for having little support for imperative programming constructs. This seems to have been by design, but it doesn't seem to make very many programmers happy.

In the Ruby world we have Rake. Rake, by contrast, has a much nicer syntax than Ant. It also allows any construct that the Ruby language allows, since Rake is just a DSL-like API for building software running in a Ruby interpreter. On the other hand, if you have the need to perform common tasks in the Java world, then it lacks a bunch of standardized cross-platform tasks that Ant contains. You find yourself breaking out into lots of icky shell commands (`javac -classpath #{my_files}`) and this works great until you try and build something on, gasp, Windows.

A pragmatic (but not so great) reality is that most Java shops may warm to switching to a different build technology, but are unlikely to switch over projects en masse. Even if they were enough in love with Rake to switch, they'd need to hobble together replacements for tasks that they take for granted in Ant. That is... until now.

Use Cases

JRuby's Rake and Ant integration handles the following use cases:

• Call any ant task or type from within Rake
• Allow Rake to be invoked from within Ant
• Allow Rake tasks to be imported as callable Ant targets
• Allow Ant to be invoked from Rake
• Allow Ant targets to be called as Rake tasks from within Rake

Let's break these down one at a time...

Call Any Ant Task or Type From Within Rake

The truth is, Ant is really just a built-in library in JRuby. You could just write a script and not use it in Rake:

require 'ant'

ant do
  build_dir = "java_build" # Regular Ruby variables interact fine

  # But defining and consuming Ant properties is fine
  property :name => "src.dir", :value => "java_src"

  path(:id => "project.class.path") do
    pathelement :location => "classes"
  end

  mkdir :dir => build_dir

  javac(:destdir => build_dir) do
    classpath :refid => "project.class.path"
    src { pathelement :location => "${src.dir}" }
  end

  jar :destfile => "simple_compile.jar", :basedir => build_dir
end

This example constructs an instance of an Ant project, then makes a directory, compiles some Java source, and finally, generates a jar file of the results. All of these are just Ant tasks. They'll work on any platform. Sweet, I say! This does, however, lack dependency management.  So let's use Rake to do it instead:

require 'ant'

build_dir = "java_build"
file build_dir

task :setup => build_dir do
  ant.property :name => "src.dir", :value => "java_src"
  ant.path(:id => "project.class.path") do
    pathelement :location => "classes"
  end
end

task :compile => :setup do
  ant.javac(:destdir => build_dir) do
    classpath :refid => "project.class.path"
    src { pathelement :location => "${src.dir}" }
  end
end

task :jar => :compile do
  ant.jar :destfile => "simple_compile.jar", :basedir => build_dir
end

task :default => :jar

[Quick note: since we can combine the best of both worlds, you don't need to ever set an Ant property if you don't want to. Just use a Ruby variable or constant. Different folks for different strokes...]

This snippet shows how easy it is to consume Ant tasks in a Rakefile. Really, JRuby's Ant library is just a straight-forward set of APIs that map clearly to Ant's original syntax. Looking up how to do something is a very straight-forward task.

The other benefit mentioned above is that Rake can use imperative programming in it. Let's consider a snippet like this in Ant:

      <java classname="${mainclass}">
        <arg value="--command"/>
        <arg value="maybe_install_gems"/>
        <arg value="--no-ri"/>
        <arg value="--no-rdoc"/>
        %lt;arg value="--env-shebang"/>
      </java>

It can use imperative conveniences:

command = "--command may_install_gems --no-ri --no-rdoc --env-shebang"
ant.java :classname => "${mainclass}" do
  command.split(/\s+/).each { |value| arg :value => value }
end

So if you're a Rake user already and you need to do Java things, then using this support should be a pretty simple decision. Heck, there are many other optional Ant tasks that may be useful even if you're not doing Java things.

Allow Rake to be Invoked From Within Ant

If you have the ability to write the equivalent of an Ant project using Rake, then you may want to make part of your project driven by Rake. However, if you do this, you may still need to call it from within Ant. We can do this with the new 'Rake' task.

If we pretend the previous Rakefile existed parallel to a build.xml file we have then in that Ant's build.xml file we could have:

<?xml version="1.0" encoding="UTF-8"?>
<project name="foobar" default="default" basedir=".">
  <description>Builds, tests, and runs the project foobar.</description>

  <target name="load-rake-task">
    <taskdef name="rake" classname="org.jruby.ant.Rake"/>
  </target>

  <target name="default" depends="load-rake-task">
    <rake task="jar"/>
  </target>

  ...
</project>

This Ant script's 'default' target will load our Rake task and then call Rake (file defaults to 'Rakefile'), and more specifically, call the task 'jar' (task defaults to 'default'). There are a couple of cool scenarios to consider here:

1. Try Rake by only dipping your toes in the water

This strategy is great if you like Rake but are worried you don't have enough influence to get your development team to switch their entire build suite. You can just stick a Rakefile off to the side for some new functionality and let your teammates evaluate how much they like it. If they do, then switch the rest later... or don't. The idea that most Java shops will big-bang change their build software is extremely unlikely. An incremental strategy is your best bet.

2. Easier integration with Java tools

Even if you're totally sold on Rake, you still need to know that software like NetBeans expects to see a build.xml file, so it can interact with your project. Having a small shim like the one above makes you play nice with any tools that expect Ant.

This is the simplest way to call Rake from Ant, but the next option may suit your needs better...

Allow Rake Tasks to be Imported as Callable Ant Targets

The big missing feature of the Rake task in the script above is that it's only one-way. You can call Rake, but then the Rakefile you call has no meaningful interaction with the Ant side of things. Sure it can call Ant tasks, but it can't see properties or Ant targets that are defined in the calling build.xml file.

To have better interoperability we have another Ant task: RakeImport. RakeImport will require the specified Rakefile and then register all of its tasks with Ant dependency management system. Let's look at a simple example:

<?xml version="1.0" encoding="UTF-8"?>

<project name="foobar" default="top-level" basedir=".">
    <description>Builds, tests, and runs the project foobar.</description>

    <taskdef name="rakeimport" classname="org.jruby.ant.RakeImport"/>
    <rakeimport/>

    <target name="top-level" depends="its_in_rake" />

    <target name="its_in_ant">
      <echo message="ant: its_in_ant"/>
    </target>
</project>

In Ant, we specify that we want to use RakeImport and then immediately call it. This loads the following Rakefile and registers all of its tasks with Ant:

task :its_in_rake => [:setup, :its_in_ant]  do
  puts "it's in Rake"
end

task :setup do
  puts "setup in Rake"
end

Now let's run 'ant top-level'; we now see the following output:

Buildfile: build.xml
[rakeimport] (in /Users/enebo/work/akakamiari/samples/rake_import_example2)

setup:
setup in Rake

its_in_ant:
     [echo] ant: its_in_ant

its_in_rake:
it's in Rake

top-level:

BUILD SUCCESSFUL
Total time: 7 seconds

This output shows that it's executing both Ant targets and Rake tasks in the desired order. its_in_ant executes as a dependency of its_in_rake which in turn executes because it is a dependency of the Ant target 'top-level'.

The scenarios for this level of integration:

1. Choosing the best tool

Since Rake gives a full imperative programming environment there are some things that are trivial to do in Rake which are cumbersome (or impossible without writing a custom Ant task) in Ant. You can move that stuff into Rake, but still continue using Ant for everything else.

2. Toe wet... time to go waist deep

In the previous section we used the Rake task to demonstrate to your development group that Rake is useful. This allows you to start depending on the capabilities of Rake more by being able to inject Rake tasks into the Ant dependency graph. Your group is still using Ant as the main build tool, but you're delegating more of the build to Rake.

Allow Ant to be Invoked From Rake

Let's look at things from the other side of the coin. If you're already a Rake user, but you need to interact with existing Ant build files, we've also got solutions for you. The first method allows you to just call Ant from within Rake:

task :call_ant do
  ant '-f my_build.xml my_target1'
end

Alternatively, you can also supply arguments as a list:

args = ['-f', 'my_build.xml', 'my_target1']
task :call_ant do
  ant args
end

Believe it or not, this doesn't just execute `ant`; it loads it into your JRuby environment. This is nice because it doesn't spawn a second JVM to run Ant.

As I mentioned at the beginning of this section, you may want to just call into Ant, but not have any more interaction than that. That's ok, but if you want more....

Allow Ant Targets to be Called as Rake Tasks From Within Rake

'ant_import' beats 'ant' in flexibility because it ends up registering all of Ant's top-level targets with Rake's dependency management system. Once you import an Ant file into Rake, you can call the Ant tasks as if they were ordinary Rake tasks. A simple example:

task :ant_import do
  ant_import
end

task :compile => [:ant_import, :its_in_ant_setup] do
  # Do some compilation
end

This example will load ant_import when the compile task is executed which will in turn load the build.xml file in the current directory and load all of its Ant targets. I did not ant_import at the top-level of the Rakefile to show that you may only want to load the Ant targets if you are actually planning on using them.

Details Details

This code has just landed in JRuby trunk. All of the examples listed here should work, but this code is brand new. It's a work in progress that will firm up by the time JRuby 1.5 is out. So this means two things for the reader:

1. You can help find problems and help improve the library

In other words, if this interests you, then you can get involved early and help address problems or enhance the library. Odds are you can make the difference between this integration being great or merely good.

Getting started note: the current practice for running the examples above is to copy jruby-complete.jar into $ANT_HOME/lib. You can manually set your classpath to include jruby-complete.jar as well, but I found it less error prone to just copy the jar.

2. If you don't like unfinished software then wait for 1.5

Some people don't like the hassles or have the time to play with unfinished software. If you're in this position, then don't worry. We'll get things working nicely for 1.5. We don't want an early test run to ruin anyone's expectations.

Conclusion

Going back to our original Mr. Potato Head theme, I was hoping to show that sometimes combining things together really is the best strategy. In theory, it's nice to start over and make something pure and wonderfully homogenous. In practice, there are always pesky real-life details that get in the way. Why rewrite everything when you can just attach the new technology on the side? If you do have the long term goal of replacing an older technology, why not do it incrementally? Every big-bang rewrite project I have ever been in has basically failed in a significant way. Change things one piece at a time and your chances of success are much higher.

Our new Rake/Ant integration is meant to allow incremental change, or at least to allow the best features of each tool to be used together. It embodies the reality that both tools may be necessary and that replacing one for the other probably won't be a 100% solution.

As always, questions and comments are welcome!

When Java first came out it was a nice incremental improvement over languages at the time. Not only was Java a reasonably simple, yet evolutionary language (vs. C or C++) but it was also a virtual machine that ran a fake non-hardware-specific bytecode (e.g. hardware-neutral). It was garbage collected, so memory management and core dumps suddenly became a minor concern. It also had a reasonably comprehensive class library. No new unique features, but a good combination of ideas packaged into something useful.

In an attempt to market Java as a simple single-named entity, though, I think Sun made a long-term marketing mistake. It co-mingled the language and the runtime under the same name. This did a huge injustice to the runtime because the Java Virtual Machine (JVM) is remarkable on its own merits. It has also made it difficult for alternative JVM language projects like Jython or JRuby to explain the virtues of the JVM without confusing it with the Java language.

This post will focus on the good and the bad of the JVM, and by the end of this entry, I'm hoping you'll appreciate all the JVM has to offer.

One final note before I delve further: this will just cover what I know about Sun's JVM. There are a few other JVMs out there and they're all remarkable in their own right. Many of my points no doubt also apply to those VM implementations, but my lack of intimate knowledge of them compels me to disclaim :)

The Bad

No technology is perfect. The JVM is certainly no exception. If you work on a non-Java language implementation you realize that you're not quite in Eden. It provides a great base for other languages, but the VM wasn't originally designed with other languages in mind. This forces us to get creative at times.

For example, we maintain our own frame stack as heap-allocated objects. If we had our way, we would manipulate the real frame stack directly and add the additional fields we need to maintain. It's too bad we cannot have better control over the framestack. Bummer.

It's also a bummer that every time we create a Ruby Fixnum value, we're boxing those values in a Java object. The C implementations of Ruby are just passing tagged ints. If only we had faster fixnums. Java primitives do not cut it since they will not fit into heterogeneous lists without boxing.

Aside: you may have also noticed that the JVM takes some time to start up :)

People who have to write high-performance code for the JVM will also find themselves frequently frustrated by the black box nature of the VM. Once you load your bytecode, you turn a crank and hope you come up a winner. You're never sure how much of a winner you will be... black boxes, by definition, are a mystery.

With all of that said (and believe me we have a laundry list of features not mentioned that we would like to see), I am super happy that our implementation is on top of the JVM. Why?  Read on...

The Good

Hotspot

For starters, I'll say that although Hotspot is a mystery, it does a generally great job at performance. The truth is that dynamic profiling is the path to excellent performance. HotSpot is much more clever than we are. It has the benefit of profile data from the running application to inform itself.

It also has the ability to de-optimize code. As strange as it sounds, this detail ends up being the catalyst to great performance.  When Hotspot does an optimization it puts a cheap guard in front of the optimization to make sure the rationale for the optimization still holds true. If the guard ever fails then it de-optimizes back to a slow path. The reason why this rocks, is that Hotspot can then be super speculative with aggressive optimizations. If the informed bet pays off, it pays off huge. If it doesn't pay off, it gets reset with additional knowledge for a future potential optimization and some extra cost for trying out the not-quite-right optimization.

Here's a demonstration of Hotspot in action:

In this graph we're running a mandelbrot generator many times and plotting the amount of time it takes to generate it each time. If you look at JRuby 1.4.0 on the right side JRuby is clearly smoking Ruby 1.8.7 and doing very well against 1.9.2preview2. If you look at the progression as JRuby starts, you can see that we start slower than 1.8.7 but rapidly pick up steam as Hotspot kicks in.

There's one interesting slowdown which occurs in iteration 6; this is actually a Hotspot deoptimization occurring. You'll also notice that performance returns to the same level. Later optimizations end up getting that performance back.

I cannot imagine writing something as good as Hotspot. It has been worked on by a lot of smart folks for close to a decade now. The improvements between Java 4, 5, and 6 are pretty impressive. As JRuby, we not only get Hotspot for free with no work on our part, but we also get improvements every time it's upgraded. This is a pretty nice perk to using the JVM. As I said nothing is perfect, but this really is an easy decision... and we've not even begun to talk about Garbage Collection (GC).

Garbage Collection (GC)

The Java folks have literally spent centuries worth of hours debugging, testing, and improving their VM. Think about a building full of engineers working on just garbage collection for a decade and a half! The JVM ships with multiple garbage collectors, so even in cases where workloads confound one GC in the JVM, the JVM actually allows you to use one of the other garbage collectors. On top of that, you can tune any of the collectors you use. You can tailor the collector for your application.

The various collectors also boast many delicious attributes. They are all compacting, so memory fragmentation is not an issue. They're all incremental to reduce the length of GC pauses which can happen. They are also generational, so that short-lived objects can be collected much more quickly.

Some are parallel so that collection work can be spread out over multiple cores. There are even concurrent collectors so that there may be no collection pause at all. Cool stuff which is also battle-tested. JRuby gets all of this for free. Now with Java 7 (and u12 of Java 6) they even have a new 'G1' collector. It just keeps improving.

There are two more neat things about GC and the JVM: both are about getting visualization and information about how well GC is coping. The first is the -J-verbose:gc flag. This option will log all collection events along with when, how much, and how long they take. This is super useful for getting a picture on how good or bad the collector is at handling your workload:

[GC 16000K->3727K(82496K), 0.0396636 secs]
[Full GC 13021K->5802K(82496K), 0.1468975 secs]
[GC 21802K->9769K(82496K), 0.0292348 secs]
[GC 25769K->12535K(82496K), 0.0243674 secs]
[GC 28535K->13136K(82496K), 0.0169928 secs]
[GC 29136K->15498K(82496K), 0.0213308 secs]
[GC 31498K->16911K(82496K), 0.0213301 secs]
[GC 32911K->19413K(82496K), 0.0186457 secs]
[GC 35413K->20207K(82496K), 0.0146396 secs]

You can tally these events and figure out total time spent just cleaning up garbage and also figure out if perhaps your workload is overburdening the collector. This may lead you to change your design or perhaps try and tune it out by changing your heap size.

The second is just querying a JVM through jconsole. jconsole has many views into the system, including ways of manipulating aspects of the system, but it has a nice memory tab to show how well GC is working:

In the lower right corner you can see green boxes showing how full different generations of memory are.  If, for example, you saw a nearly full survivor generation (the empty third bar above), then that means slow full GC collection times, and it is very unlikely to be a healthy application.

Portability

Both GC and Hotspot are available wherever Java is available. This means JRuby will not just work on other platforms, but that it will work well on other platforms. It's really nice to get this support for free.

On top of that, JRuby is working in exotic locations. We get bug reports for JRuby bugs on OpenVMS. People tell us about Rails applications running on JRuby on an IBM mainframe running CP/CMS! I am not making this up. Crazy and cool to think that people have an oasis in JRuby on OSes like this. We can thank the portability of the JVM for this.

In fact, since the open sourcing of Java and the OpenJDK project, we are seeing even more proliferation of the platform.  I think the portability proposition is about as perfect as it can get.

Maturity

The JVM is over 15 years old—maybe even old enough to get into an R-rated movie. At JavaOne the parallel was drawn between a child coming of age and the longevity of Java and the JVM. Over the last decade and a half an impressive amount of engineering effort has been expended to make the JVM stable, fast, and pervasive. Oh yeah... we get that for nothing! Is this sounding familiar?

On the Radar

JRuby and other language projects on the JVM have been acknowledged by JVM engineers. A concrete example is the invokedynamic specification (aka JSR292). This JSR is tailored for new languages and the fact that Java method dispatch rules are not the only ones which matter on the JVM. It is nice that the JVM wants to be a better platform for projects like JRuby.

There is also a MLVM (multiple language VM) project which is a clearinghouse for new features which may make it into the JVM. It's at least a place where enterprising developers can try to add features they want to see in the JVM. The JVM engineers themselves interact and make suggestions. This looks like it's becoming a great incubator for new JVM features.

These two developments make me happy that the JVM is expanding its scope and watching what people are using it for.

Time Marches On

The JVM has become a durable part of the technology landscape. The uncertainty of an Oracle/Sun merger and any potential shenanigans makes for salacious technology press, but the truth is mundane. So many behemoth companies (like Oracle and IBM and HP and SAP and.... and...) have invested so much money in writing middleware for the JVM that it's difficult to see their commitment to the JVM changing in the next decade.

What this means for JRuby is additional performance gains and additional opportunities to help influence the market towards a language like Ruby, and Ruby on Rails. We're doing what we can to help Rubyists satisfy their desires in a Ruby runtime. At the same time, we're also showing Java folks that Ruby is a language with lots of advantages over Java for many applications, but one that they don't have to change their platform to use.

Warning: Most of the code you see in this post should never be used in real life by actual programmers. The snippets are meant to provide insight into the power of Ruby, and more obviously, are for entertainment value.

1. Expressions are Cool

One of the great things about Ruby is that everything is just executable code. In fact, everything is an expression. This makes it nice because you can then programmatically build up a set of methods in a class body, like this:

class Numeric
  MM_SIZE = 0.00025

  [:mm, :cm, :dm, :m, :dam, :hm, :km, :Mm].inject(MM_SIZE) do |size, unit|
    define_method(unit) { self * size }
    size * 10
  end
end

Ignoring the fact that I just modified Numeric, you have to admit that being able to do stuff like this in Ruby makes it a great language; a language with the flexibility to define methods progammatically because everything is just code and expressions.

Over the years of supporting JRuby, I began to realize that the grammar is a bit too too generous. At this point you can argue that it's up to programmers to hang themselves with any bizarre language feature. So what's the fuss?

def foo(a, b=def foo(a); "F"; end)
  a
end

p foo("W", 1) + foo("T") + foo("bar")      # => "WTF"

Is there a sane reason to allow a def as the value of an optional argument? Since we have a language where everything is an expression, this is just life in the Ruby lane. Luckily, def returns nil and not UnboundMethod or something that's considered useful; otherwise there would be some pretty weird code floating around.

Before I go on, I wondered about variable scoping...

def foo(a, b = self.class.send(:define_method, :foo) {|_| ": I captured #{a}" })
  a
end

p foo("foo") + foo("bar")  #=> foo: I captured foo

Of course it makes sense that the optional argument value of 'b' evaluates in a scope where it can capture 'a'... but wow! The potential for strange Ruby code is just amazing!

2. It Makes Sense But...

Other times the grammar has oddities which seem to make sense on the surface but generally confuse you when you start to stray off the path of idiomatic Ruby. Heredocs are a great example:

a = <<EOF
hooray
multi-lines
EOF

This how we normally see them. The idiomatic example may have us define a heredoc as: when encountering a heredoc statement (<<EOF) take all lines after that statement until we encounter the heredoc marker on a line by itself and use those lines as a multi-line string. Certainly, that would still work for this example:

{:skybox => "/data/skyboxes/mountains/",
 :floors => [
  {:location => [0,0,0],:data => <<EOL, :texture => "data/texture/wall.jpg"},
........BCB.........
.........P..........
....................
........DDD.........
.......D....D.......
....................
....D.....D....D....
....................
..D....D....D....D..
...BBBBBBBBBBBBBB...
EOL
  {:location => [0,10,0],:data => <<EOL, :texture => "data/texture/wall.jpg"},
# More elided ...
}

Heredocs in this code are interleaved in the middle of a hash literal... This is odd, but the definition still holds up. Let's break the definition:

def foo(a,b)
  p a, b
end

foo(<<ONE, <<TWO)
This is one
ONE
This is two
TWO

Two heredocs on the same line break the definition. I think with a little work we could fix the definition to talk about what to do about multiple heredocs on the same line, but then consider this case:

a = <<ONE
This is one. #{<<TWO}
This is two. #{<<THREE}
This is three.
THREE
TWO
ONE    # => "This is one. This is two. This is three.\n\n\n"

Coming up with an easy to read definition is starting to get rough. Maybe just accepting that you can do weird things with heredoc without actually explaining them in a common definition is the right thing to do. Do we really want people to use heredocs this way? Is it cool that we can do stuff like this?

3. Mystical String Concatenation

Ruby's grammar is huge. Super huge, and sometimes you see something in the grammar that makes you wonder how it got there. For me the one I wonder about the most is what I call the "Mystical String Concatenation" feature:

string        : string1
              | string string1 {
                  $$ = support.literal_concat(getPosition($1), $1, $2);
              }

Since string1 must be a type of string literal this translates into the following Ruby syntax:

a = "foo" "bar"
p a # => "foobar"

Is this really useful? The performance benefit is that the parser will concatenate the string before any execution happens.... but this only works for string literals! A programmer could just rewrite the string as "foobar". Perhaps someone wanted to inspect strings into an eval statement?

one = "foo"
two = "bar"
a = eval "#{one.inspect} #{two.inspect}"

It mystifies me...

Conclusion

Ruby is beautiful, powerful, and in some cases, wacky. I've only just scratched the surface of the weird convoluted things you can do with Ruby's syntax. What's most interesting to me though is that Ruby programmers rarely touch these strange bits unless they're trying to be cute...

Compared to another language I used to always use (it starts with a P and is four letters, but I seem to have completely forgotten its name...), it's surprising how rarely real Ruby code ventures into the land of the indecipherable.

Both Ruby and the previously mentioned forgotten language are very powerful, and can get a lot of the same things done, but it seems that Ruby code ends up being written in a largely idiomatic way. Ruby may be a rat's nest for writing a coherent specification of the language, but the Ruby that people write using this underspecified language ends up looking really nice.

There are thousands of useful Java libraries out there that are usable from JRuby, but just importing and consuming them directly is not always very appealing. This is largely in part because these Java APIs do not use any Ruby features. In other words, the API feels like a Java API (duh!). So as you've probably already guessed, the rest of this entry will be about pimping out Java APIs with the workhorse Ruby features we all know and love.

What You Get by Doing Nothing

Even if you don't try and make a better API, JRuby does several things to Java classes to help narrow the gap:

1. All methods can be snake-cased:

setSize 200, 200

can be:

set_size 200, 200

2. Getters can omit the get:

my_height = frame.getHeight

can be:

my_height = frame.height

3. Setters can be replaced with assignment:

event.source.setText("Yeeeeehaw")

can be:

event.source.text = "Yeeeeehaw"

4. Last arguments which are interfaces can just be a block instead:
   This is much more common in Java APIs than you would think:

class MyListener
  include java.awt.event.ActionListener
  def actionPerformed(event)
    event.source.text = "HEEEE"
  end
end

instance_of_action_listener = MyListener.new
button.add_action_listener instance_of_action_listener

button.add_action_listener { |event| event.source.text = "HEEEE" }

5. Common Java types have been infused with some common sense Ruby behavior:
   For example, all Lists and Maps have an each() method and mixes in Enumerable.

We try our best to make Java classes not look alien in Ruby, but they're still basically a Java API with a minor face lift. You need to put a little work into Ruby API design to take Java classes to the next level.

Decoration

Before I explain decoration, I need to give one detail about how Java classes get imported into JRuby. When a java_import is done:

java_import java.util.ArrayList

This will construct a Ruby Class in the current namespace called ArrayList or a Ruby Module if we were importing a Java interface. The Ruby class/module defined will have one method per distinct name in the Java class/interface which will dispatch to the appropriate Java method via lots of magic for Java signature overrides and static-type resolution. From this we can say:

'Anything imported from Java is actually fronted by a Ruby class/module that can be manipulated like any other Ruby class/module'

With this knowledge, decoration is just manipulating these Ruby proxies like any other Ruby class/module. If you want to add a method which has optional parameters, then just open the class and add the method you want. You can do anything you can think of including things like: aliasing, removing methods, adding instance variables, or even add a method_missing.

So let's look at a concrete example. In JRuby source itself, we decided that anyone who uses any class derived from the interface java.util.Map should be Enumerable. We do it with decoration:

module java::util::Collection
  include Enumerable

  def each(&block)
    iter = iterator
    while iter.has_next
      block.call iter.next
    end
  end

  def <<(a)
    add(a)
    self
  end

# ...
end

So because of this we can do things like:

require 'java'
arr = java.util.ArrayList.new
arr << 1 << 2 << 3
arr.inject(0) { |sum, i| sum += i }

So this makes ArrayList feel just like Ruby's Array sans construction. Decorating is a nice way of bridging the gap with a little bit of Ruby code. It also helps encapsulate the use of Java API code into one place.

BEEP BEEP BEEP

The Java people reading this may be excited thinking "oh wow! I can add methods to Java classes." Realize that anything you add will only be seen on the Ruby side of the fence. For Java classes, type signatures are frozen when the class is compiled. No amount of JRuby magic can change this aspect of Java.

Additionally, if you want to change behavior of an existing method and have Java see that change, then you need to extend the Java class (e.g. class MyArray < ArrayList).  In a future blog entry, we'll talk about implementing Java interfaces and extending Java classes within JRuby, so keep an eye out.

Blocks

It should be old hat for most Rubyists to make nice APIs using blocks. I just wanted to point out just how helpful they are when trying to change a blockless API to one which uses blocks.

In Java, one of the most hated aspects of coding is large number of try/catch/finally statements. Ruby has the equivalent with begin/rescue/ensure but have you ever noticed how much less we see the Ruby-equivalent constructs in Ruby?  try/catch literally riddle the landscape of Java. Encapsulating these exceptional paths into to a method which accepts a block is a clear winner and should be used when you encounter this in a Java API. This is especially true for APIs which need to demarcate something transactional in nature.

In fact, there is lots of repetitive code in Java which can be DRY'd up with some simple block idioms.

Another problem in Java that festers because of lack of blocks is poor syntax for anonymous classes. It is so verbose that most people will opt to write one-off named classes. This ends up causing lots of extra files or extra lines for inner classes. Blocks make it really easy to kill off one-off classes. Here's a code snippet I used in the JrME library:

class InputAction
  # Make an action which will invoke the supplied block every time there
  # is an action event:
  #   forward = InputAction.create { |event| node.accelerate event.time }
  def self.create(&block)
    BlockBasedInputAction.new(&block)
  end
end

class BlockBasedInputAction < InputAction
  def initialize(&block)
    super()
    @block = block
  end

  def performAction(event)
    @block.call event
  end
end

In one small demo game which I ported from Java, I ended up removing three separate application-level classes because I made this one tiny library-level one. It's surprising how nice some Java libraries seem after adding a few strategic block-accepting methods.

Delegation

Delegation as a concept is not specific to Ruby, but is worth bringing up. Why decorate a Java class and get all of that Java class's methods exposed when you can hide them behind another Ruby class that only exposes what you want? This is especially powerful when you want to write a common API that works across multiple Ruby implementations (e.g. JRuby, MRI, and Rubinius), but has different native backends.

Domain Specific Language (DSL)

Ruby provides the capability to make code soooo much more readable by doing some syntax gymnastics and making a DSL. Java has absolutely no chance in this area. I made a simple DSL in JrME for physics object descriptions which I thought turned out well. In fact, let's look at a before and after...

This abbreviated Java snippet creates a cube that is made of ice with a texture map at a particular location:

/* Missing try/catches.... */
DynamicPhysicsNode iceQube = getPhysicsSpace().createDynamicNode();
iceQube.attachChild(new Box("Icecube", Vector3f.new, CUBE_SIZE, CUBE_SIZE, CUBE_SIZE));
iceQube.generatePhysicsGeometry();
iceQube.setMaterial(Material.ICE);
TextureState textureState = DisplaySystem.getDisplaySystem().getRenderer().createTextureState();
URL url = System.getResource("data/images/Monkey.jpg");
Texture texture = TextureManager.loadTexture(url, Texture::MinificationFilter:Trilinear, Texture::MagnificationFilter::Bilinear, true);
texture.setWrap(Texture::WrapMode::Repeat);
textureState.setTexture(texture);
setRenderState(textureState);
iceQube.computeMass();
iceQube.getLocalTranslation().set(START_X, START_Y, START_Z);

Caveat: a good Java programmer would organize this code and make abstractions that make sense for Java. They would not vomit it into one stream like this. However, I just wanted to show how much work the DSL does, so I think it is okay to show it this way.

Here's what this code looks like using the Ruby DSL:

@icecube = physics_space.create_dynamic do
  geometry Cube("Icecube", CUBE_SIZE)
  made_of Material::ICE
  texture "data/images/Monkey.jpg"
  at *START
end

DSLs are not for everyone and certainly not for every occasion, but when they fit, nothing can beat them.

Scratching the Surface

I've just provided but a few examples of the many ways to Rubify Java APIs. Beyond the explanation of java_import, this was all just basic Ruby programming. If you can write a good Ruby API, then you'll have no problems wrapping a Java API. I prefer to use pure-Ruby libraries when I can, but I cannot ignore all the cool and useful libraries that the Java ecosystem has produced over the last 15 years.

Keep an eye out for more JRuby content in the coming weeks, and feel free to comment with any requests!