JRuby is much more than a Java version of MRI Ruby

Ruby JRuby
1

In a recent thread I questioned whether it mattered if there was a
roadmap to MRI Ruby 2.x compatibility and later I said “So it seems
JRuby plans to remain subservient to MRI Ruby. Pity.” Among the replies
someone said “what other path could JRuby take?”. And Charles Nutter
said “I believe we have done more to advance Ruby than any other
implementation”.

I have great respect for Charles and I don’t disagree with his claim.
But I firmly believe that JRuby can be much more than it is.

I didn’t pose my original question because I object to the changes being
implemented in MRI Ruby 2.1 - I have no idea what they are (I have not
out-grown JRuby 1.7 yet). But I was trying to get the JRuby community to
question its own direction.

It seems to me the focus for the JRuby community is on compatibility
with MRI Ruby rather than on JRuby as a product in its own right - a
product which should follow its own future development path (which may
or may not include compatibility with MRI Ruby). It only needs to be a
useful tool for programmers.

What would be wrong with a future in which MRI Ruby strives to be
compatible with JRuby. Even now that would be a much greater challenge
considering the breadth of JRuby’s capabilities.

To my mind there are three great strengths of JRuby that are hardly ever
mentioned. It is trivially easy to install on any PC that already has
the JVM installed (though the standard installation is not nearly as
simple as it could be). It can easily be used to produce GUI programs by
drawing on the underlying JVM. And most apps written in JRuby will run
unchanged on any other PC just by copying the project so they can easily
be distributed to non-expert users. The only external dependency is the
JVM which many PCs already have installed. By contrast, “Aunt Mary”
would find it impossible to install an MRI Ruby application.

These features should make it very attractive to beginners to
programming and to anyone who wants to create a cross platform GUI app
but no effort seems to be made to reach those markets. The underlying
assumption seems to be that people (experienced programmers) find JRuby
after they find MRI Ruby (probably by way of Rails).

I understand that the developers of JRuby are much better and more
knowledgeable programmers than I could ever hope to be. But sometimes
experts are too focused on their expertise to see the wider world.

…R

2

Bonjour Robin

(sorry for my bad english: you’ll have to guess what I mean :wink:

Another strength of JRuby you didn’t mention is that JRuby is a
Ruby interpreter.
So if I write a native (MRI) ruby script, it can easily be ported on the
Java plateform.

In fact, several years ago, I switched from Groovy to JRuby only because
Sun decided to support the JRuby project. So I could count on one same
language either on the Java plateform or some native plateform.

If Groovy had a native version like MRI, I’d probably never go for
(J?)Ruby.

And if JRuby is no longer compatible with Ruby, it loses its main
interest because there are already exists numerous other nice
languages for the JVM.

Regard,
– Maurice

Le 25 fvr. 2014 17:42, Robin McKay [email protected] a crit :

3

I think this is a matter of priorities. The Jruby team is and should be
concentrating on making a viable ruby interpreter and are doing an
excellent job of it. The rest of the stuff you are talking about are an
ecosystem that grows around the language. There are already frameworks
built around SWT and Swing, there is shoes which is being ported to
jruby,
etc.

The people who work on jruby should work on making the most awesome,
fastest, leanest, meanest ruby interpreter possible. It’s up to the rest
of
the community to build on that base.

4

Let’s chime in as someone who spends most of the time with Ruby
community gardening.

I think this is misguided on many levels. First of all: MRI isn’t bad
per se, widely used and - despite its problems with concurrency -
still a very usable piece of software.

I question the triviality of installing JRuby somewhat. Ruby installs
using a standard “./configure && make && make install” process and
I see “Aunt Marys” (what is that, in any case?) doing that all day. It
fits on UNIX systems very nicely, as good as JRuby fits in JVM
environments.[1]
The easy distribution is a fun thing, I know that the Shoes team
is struggling with that for month now. I know far more successful
projects vendoring MRI than a JRuby. (e.g. Vagrant)

Details aside, what would be wrong with a future where MRI strives
for JRuby compatibility? Everything. JRuby is finally making a
effort for being fully compatible with Ruby 2.1[2]. So we finally,
after years, reach a point where both implementations are on
the same level, language-wise. Then deciding to take over
the language development would be a disservice to the
community that I don’t think will be very welcome.

JRuby, in my opinion, is more successful than similar projects
like Jython because the team is humble, very constructive,
cares about compatibility a lot and has a long breath. Also,
they are not shy of any discussions with the MRI team, see
the long discussions about Refinements that ultimately led to
something usable.

I am also under the impression that JRuby serves users first
and then plays politics. The ability to get Ruby code working
on and off the JVM without many assumptions about JRuby
and MRI is one of the big strengths of the Ruby environment.

Another project going mental and deciding to build their own
Ruby interpretation doesn’t sound like a good future, community-
wise. We don’t need a JRuby X and I would never touch it.

I’d prefer a future where the MRI and JRuby team plan new
things together better.

Also, as final note: I like the direction where Ruby is going
language-wise, so I don’t see a need for someone taking
over in any case.

Best,
Florian

[1]: I am running a beginners board and training beginners.
[2]: Except some runtime features, e.g. C exts.

5

I should add that stackoverflow is filled with questions about why some
gem
that depends on native libs isn’t installing. On the Mac there is a
series
of hoops you have to go through installing xcode or the xcode tools and
then a bunch of brew installs before you can install a database gem or
nokogiri or anything else. On windows it’s even worse. This is where
jruby makes a big difference because there is no compilation step and it
“just works”.

6

Hi Tim,

the “just works” part is relative: If you want to use gems that use
native extensions on jruby, those will require the same series of hoops
to jump through. However, you can distribute prebuilt binaries for all
gems that require native extensions if you’re so inclined. Tokaido
(Rails Installer) and Vagrant both manage to do that just fine. No brew,
no compiler, it “just works”, even when using MRI. So if you want to
distribute pre-built applications that require only a single “install me
that” step, you can do so. Installing a development build or a
development environment is much more involved, but that’s a different
thing.

Regards
Felix

7

Vagrant is good for development but I don’t think people will want to
run
each app in it’s own virtual machine. Docker is more suitable for that
kind
of thing. In my case the devs use Macs (mostly) but the deployment is
on
linux so the gems have to be compiled for both Mac and Linux. If one dev
adds a gem another dev has to install the external dependencies to
install
that gem via brew. If we were using jruby it would be a jar and it
would
work on both linux and mac.

I haven’t found too many gems that won’t work on jruby. Jazz Hands is
the
only one that comes to mind immediately

8

I second this post, especially the final note. Well nailed.

One should consider the difference between the “wider world” and the
practical world (ie the reality vs wild imagination or dreams).

I for one started with ruby when rails was not even baking. At that time
we
did not even have the ruby gems system.

Gems and rails changed the ruby ecosystem. From a community of
specialized
developers, it grew and grew.

Maintainability and sustainability became important, especially with
gems
containing extensions. Hence ruby gems has to have a better dependency
management (bundler).

We saw other ruby implementations appear. Many… Each single one of
them
is a follower of MRI.

Jruby is one of many, and even though it has many java advantages (wide
java library, 1st class garbage collector, superior threading
capabilities,
etc…), it suffers from lack of publicity (success stories), it lags
sometimes on compatibility with MRI and has unfortunately still a small
audience.

Many devs discover jruby by mistake or by chance.

Many are trying the latest version of rails with jruby, and though rails
is
just the tip of the iceberg, any jruby lag with MRI or any jruby
incompatibility will be a bad publicity.

I do not see how MRI could be so influenced by any of its offsprings.
Again
jruby is just one offspring out of many.

Making jruby a reference development platform for rails might give us
more
weight or publicity. I really mean reference, not just rails X supports
jruby Y.

We should not change the plans decided by the main developers team.
Keeping
up the compatibility with MRI and its lead products/gems is the sanest
way
forward.

9

One thing I havent gotten to work with JRuby iscurses! I dont imagine
anyone else in the world needs this to work, but Im writing software to
test network servers that are headless machines we ssh into for
terminals. I have a long running program, and wanted the users to see
lots of pieces of status information as the program does its thing.
curses was the best thing I could think of. Its really clunky and I
tremble at the thought of being asked to add more information to the
screen, since everything is absolute positioning. Anyone know of a
better text mode windowing library? I used to use Vermont Views about
20 years ago, but that was a C library and Id rather not deal with
writing a wrapper for it (if I could find it at all at this point in
time). In my code I check to see if Im running under JRuby, and do not
provide the full screen interface if so.

  • Keith
10

Keith,

Someone recommended this library to me recently and it is still being
actively maintained:
https://code.google.com/p/lanterna/

FFI bindings to libcurses also seems like it could be worth the
effort.
I have not used curses from C in decades but I don’t remember it being a
huge API.

-Tom

11

I’ve been using jruby for two years, and I want to add my two cents that
it’s more than a Java version of MRI. I’ve led two teams building big
production applications with it:

  1. www.mlife.com – built in jruby with Rails, tying into a very fast
    java-based ESB. It handles millions of requests a day and doesn’t break
    a sweat, with amazing uptime.

  2. A new project that I’m working on for a large scale multi-user
    real-time system that fuses together jruby with Akka and scala. We’ve
    built first class Akka actors in jruby, some of which include components
    of Rails (such as ActiveRecord).

jruby, for us, isn’t just ruby built in java – it’s a fusion of ruby
onto the jvm that lets us open/extend any java class and build
incredibly powerful multi-threaded apps that scale.

I’ve been building high volume distributed systems for over two decades.
I laugh when I hear statements like “ruby doesn’t scale.” Anyone that
says that doesn’t understand two things: Firstly, languages don’t scale,
architectures do, and secondly : jruby.

jruby rocks.

  • Russell
12

I am the creator of RubyNEAT and would love to be able to run my Ruby
Neural Evolution of Augmenting Topologies implementation on JRuby mainly
to gain some speed benefits and also to leverage multicore concurrency.

I have elected to make my code fully Ruby 2.x and I do make heavy use of
metaprogramming, named parameters, and other features of 2.x. Because of
this, I cannot run on Rubinus or JRuby until they become fully 2.x
compliant.

I think it is very important for all MRI-alternatives for Ruby to be
able to talk the same talk and walk the same walk. In an ideal world,
the latest Rails stack or Sinatra or the vast majority of Gems not using
extensions should just run “out of the box” on JRuby.

To do otherwise would hurt JRuby and cause a fracture in the Ruby
community, forcing developers to chose what they will write for with
their limited resources or to have to resort to special-casing their
code for both environments.

This has happened already with C++ in the past, is still a bugaboo with
JavaScript (though the condition has vastly improved over the past and
the frameworks do a good job of hiding the few remaining warts).

Also, I am working hard on introducing Machine Learning to the Ruby
world, which has been neglected up till now.

Compatibility is the Synergy of Über-excellence.

13

Fred -

I’m sure the JRuby team understands the benefits of compatibility with
the latest versions of Ruby.

As I see it, their efforts to bring Ruby to the JVM, even without full
2.1 compatibility yet, are already heroic.

JRuby is an open source project with limited resources; and the authors
are individuals with limited amounts of time.

As for me, I write mostly gems, and I choose not to use new language
features, not only so that I can run JRuby, but also so that the users
of my gems can run them even if they are using older (yes, unsupported,
I know) versions of Ruby. (I currently draw the line at 1.9, using 1.9+
features.)

You might want to consider this if you want your code to be runnable
inside other Ruby code (that is, if you want your Ruby code to be
callable in Ruby as opposed to only running on its own.)

To me, the newer features are not that compelling as to justify my
losing those benefits.

Of course you’re right that it would be better to have that 2.1
compatibility now, but please understand that resources are limited and
acknowledge the effort that has already been made by the JRuby team.

  • Keith

Keith R. Bennett