JRuby pitch for Java developers?

Ruby JRuby
1

Hi everyone,

couple of months back I listened to the Ruby Rogues JRuby episode with
Charlie (http://devchat.tv/ruby-rogues/124-rr-jruby-with-charlie-nutter)
and he said that the “sales pitch” of JRuby to Java developers is very
different than from the one of JRuby for Ruby developers. And ever since
I wondered, what is the pitch for Java developers?

Java developers here, why do you use JRuby? Which problems does it solve
for you? How can we get more Java people to try out JRuby?

Thinking of it I can come up with the following points:

  • write code faster/prototyping/quicker changes
  • not type annotations everywhere
  • easier access to powerful meta programming features
  • superb Java integration, e.g. use libraries/other code easily
  • integration goes so far that you can package ruby applications as .war
  • for a tester: nicer test framework

That’s about what I can think of - and still makes it hard to explain
why people shouldn’t just go with languages “born” on the JVM
(Clojure/Groovy/Scala).

Ideas/Input/Pointers?

Cheers,
Tobi

2

(Java was my college language and only briefly a profession language,
so these may be naive responses)

Hmm, being able to create 5 line scripts to do real work (especially
if stuck in a windows environment) is pretty nice. Relatively stupid
things such as, we have to copy files whose filename contains these
numbers and are of this file type with md5sum checks on either side.

Getting access to Ruby’s Array and Hash. No more Java Vector →
LinkedList → etc. → etc. to get map/reduce/delete_if functionality.

On Sun, Jan 11, 2015 at 3:11 PM, Tobias P. [email protected]
wrote:

why people shouldn’t just go with languages “born” on the JVM

–
Incoherently,
Ricky Ng

3

I might not be the best case study
but JRuby in my Java applications
is used primarly in these situations:

  1. Querying application objects in realtime/runtime
  2. Creating reports for users in runtime inside application (we have
    special module for this)
  3. Using JRuby scripts for these parts of application that are very
    likely to change frequently (loading complicated data from xls files
    on runtime)

–
Pozdrawiam,
Paweł Wielgus.
tel: +48 604 603 546

2015-01-11 22:11 GMT+01:00 Tobias P. [email protected]:

4

I was a full time Java developer for over ten years (though I’m very
happy that that is no longer so!).

Here are my feelings about it:

So many Java developers have never worked with a scripting language.
Using a scripting language can make automation of some tasks feasible
where using Java instead would be prohibitively complex and time
consuming.

Using a scripting language that runs on the JVM (JRuby, Groovy, Clojure,
and others) provides easy interaction with a Java product’s code. This
can be handy for:

  1. unit testing (e.g. with rspec, minitest)
  2. providing an interactive shell (e.g. irb, pry) for that code. Having
    an interactive shell to exercise Java code can be mind-blowing for
    someone whose interaction with their code has been limited to an IDE and
    the OS’ command line.
  3. RDBMS manipulation - for interacting with RDBMS’s, using JRuby and
    the Sequel gem can make DB interrogation and manipulation way, way
    simpler than in Java.
    4…n) …

Ruby is a great language. JRuby is the only Ruby implementation that
can run in the same process as Java code (the JVM). So JRuby offers the
intersection of those three very valuable attributes — being a scripting
language, Java interoperability, and being the highly productive
language that we know and love.

Many times a project is mandated to be written in Java, but it’s really
only important for the production code that the application runs; other
things, such as unit tests, admin scripts, etc., can be written in
another language.

I am convinced that there is a gold mine of functionality that can be
added to Java dev teams using JRuby. Unfortunately, the mindset of most
Java developers seems to be rather bigoted against JRuby (just as so
many Ruby developers are bigoted against Java). So it’s a people
problem (as usual) that stands between us and greater value.

Some will complain that the effort of learning another language for this
is prohibitive, but my response is that if a team’s toolbelt doesn’t
include any scripting languages, then the team is functioning with a
hand tied behind its back.

By the way, I used to give a JRuby presentation that included addressing
this question (see
JRuby - The Synergy of Ruby and the JVM - Speaker Deck).
It’s a little dated, but most of it is still accurate.

  • Keith