I just stumbled across this thread, and figured I should inject a few
opinions. I am one of two active developers on JRuby, where my main
charge
has been the redesign of the core interpreter and planning for various
stages of compilation. I also recently got IRB and Rails’ generate
script
working, and I’m currently focused on optimizing the interpreter a bit
before we present JRuby at JavaOne. I’ll try to address some of the
issues
people have brought up:
- Java is slow
I had thought this myth was entirely debunked, but as others have
commented
Java is nothing like slow. In certain scenarios there’s a bit more
overhead
than on “hand-optimized assembler code” but then you probably aren’t
going
to hand optimize a million lines of assembly either. Java is actually,
in
many cases, faster than compiled C code, owing to its ability to
optimize
and re-optimize code based on usage patterns. There’s never just one way
to
optimize a code path, and the mixed-mode compilation Java does while
running
allows it to exceed native code frequently. Take a look at any of the
typical language shootouts or performance benchmarks. On equivalent
algorithms, Java is extremely fast…in many, many cases far faster than
the
current Ruby code.
The following benchmark shows Java beating Ruby by an order of magnitude
in
almost every case, though it frequently uses more memory to do it:
http://shootout.alioth.debian.org/debian/benchmark.php?test=all&lang=ruby&lang2=java15
Even if the benchmark is flawed, it’s hard to argue that an optimized
Ruby
implementation on the JVM would necessarily be slower.
- Enterprise is a loaded term that isn’t important
I agree. Enterprise has become as meaningless as SOA, Middleware, and
their
ilk. However, the concepts behind the word (or the concepts I’d like to
believe are behind the word) are very important.
“Enterprise Java” has come to mean many things to many people. If you
equate
Enterprise with Enterprise Java Beans, then you’re selling the platform
short. EJBs may have been initially compelling, but their verbosity and
complexity have doomed them to ridicule. Don’t write off the entire
platform, however. The Java Transaction API has made cross-request and
even
cross-server transactions trivial to handle. Enlisting n remote servers
into
a larger transaction is handled transparently. The Java Message Service
has
provided a simple, reliable, cross-platform and cross-server means of
handling asynchronous communications. It really “just works” and
provides
huge benefits for long-running processes and offline transactions. Java
Management Extensions, while not officially part of Enterprise Java,
provide
consistent, uniform remote administration and management capabilities,
along
with managed, monitored services throughout an application cluster. And
while we’re on that topic, clustering, failover, and session replication
within typical Enterprise Java clusters “just works” too. I won’t even
go
into JDBC, perhaps the most impressive cross-platform and cross-database
SQL
api that exists.
I am by day officially a “J2EE Architect”, though my eventual role has
me
mostly escorting other developers through the pain of writing J2EE
applications and trying to find better tools, frameworks, and patterns
to
make that process simpler. I feel all the typical pain of J2EE
developers,
and I agree there are bad areas…but don’t throw the baby out with the
bathwater.
- Bringing Ruby and Rails to Java will somehow corrupt Ruby and Rails
The goal of JRuby is to create a fast Ruby interpreter that looks,
feels,
and acts just like Ruby. We will not require any modifications to Ruby
(and
in fact we run with Ruby’s own lib/ruby/1.8 libraries), and we only
reimplement specific features where the Ruby equivalent doesn’t consider
Java’s capabilities or where Ruby implements those features in C. A
similar
argument goes for Rails: Rails must be able to run without modification
under JRuby, albeit behind a “mock CGI” Servlet that can simulate
running
with fastcgi and friends.
What we do hope to provide is a way to access Java’s good features from
within Rails. JDBC is an obvious match for ActiveRecord, and JTA can
provide
transaction support seamlessly. Once inside a J2EE cluster, we can also
enable replication and failover for Rails sessions and requests by
wiring
those subsystems into those provided by the cluster. We can wire JMS
into
available messaging libraries for Ruby, allowing Rails to submit jobs to
any
JMS-aware server (which ultimately could mean any messaging server,
since
most of them support JMS). The list goes on and on.
It is true, and must be accepted, that while Ruby the language is a
marvelous, beautiful thing, Ruby the platform still has some growing up
to
do. Unicode support is partial and inconsistent. Support for
locale-specific
calendars, messages, and behaviors is nowhere near what Java provides.
Integration with other languages and other platforms is sketchy at best.
Ruby simply lacks many features that would help it gain acceptance as
more
than “just another scripting language.” I’m certain Ruby will get
everything
it’s missing over time, but by putting Ruby and Rails on the JVM we may
be
able to have them now. Who knows, perhaps the APIs that develop out of
Ruby
on the JVM will filter back into the design process for future versions
of
Ruby.
- My plan for JRuby (though just one view of where we’re going)
I will try to lay out briefly the current plan for JRuby.
- We are currently working very hard to get Rails running for a simple
case.
The generate script already works and generates usable code and
configuration. The next step is getting Rails to handle a request. We
currently get pretty far into that process before things bomb out, and
expect to have it working by the end of this month.
- JRuby is, despite Java’s speed, quite slow right now. The original
author
just did a simple port of Ruby’s C code to what it would look like in
Java,
and as a result many JVM features that could speed Ruby up were crippled
or
impossible to utilize. My work recently has been to completely rewrite
and
rewire the internals of JRuby to enable compilation to Java bytecode,
full
continuations support, tail-call optimization, and multi-VM (running
multiple “Rubies” inside the same JVM). All of these will help improve
performance, and we hope to exceed Ruby 1.8 performance at some point.
I would welcome any questions or comments. Our main goal with JRuby is
to
provide a real Ruby environment that happens to be running on the JVM,
and
to enable Ruby code to integrate with Java code whereever it is useful
to do
so. We would be as happy as you all if Ruby were to supplant Java as the
language-of-choice, and if JRuby helps further that goal…all the
better.
Remember that J2EE is not just EJB.