The Pending Ruby/Java Co-op

December 29, 2006

What follows started out as a single bullet point from a list of predictions for 2007. It somehow went awry. As such, you would do well to consider this piece with roughly the same amount of seriousness as would be given to any other tech prediction article.

A couple of years ago I was excited about dynamic languages on the JVM and what it could mean for web developers. Then I wasn’t. Now I am again. I’ve been completely clean of Java for almost two years now but I have a feeling that might change in 2007 (probably late 2007).

Java will Eventually Not Suck

There’s basically three things that need to occur before Java gets to go back in the toolbox:

The mainline JVM must be available - the way I want it. The hardest part of this was done when Java went GPL and makes everything that follows possible.
The quantity of Java packages must go up. I want a huge inventory of libraries packaged on all popular Linux and BSD packaging systems. I’m mostly interested in FreeBSD, which already includes 148 Java related ports in the main repository, but I need to know packages exist on all major Linux distributions as well.
The quality of Java packages must go up. By quality I mean packages should be individually well maintained, patched appropriately for the intended system, and updated with little lag behind upstream. Quality is a function of eyeballs. #1 and #2 will result in an increase of eyeballs and thus an eventual increase in quality. QED
Better JVM startup time. This may be fixed already, I’m not sure. If it isn’t, it will be once #1, #2, and #3 are in effect.
JRuby running under rough performance and feature parity with CRuby.

Once these things are settled, Java becomes a serious option for me and people like me, whether we know it or not.

Java: A Better C

All Java has to do is be better than C at some of the things C does now. Java will, in effect, become the new C with a small but critical difference. Before we get into what that difference is, let’s take a look at a few of the most important things C does for web developers today:

The HTTP/web server. Must be fast, fast, fast - silly fast. Right now this is httpd, lighttpd, nginx, and Mongrel. All C.
The language interpreter: python, ruby, perl, php, etc. (I suppose java should be in that list as well :)
Lower level support libraries: libxml2, openssl, ImageMagik, cairo, glib, yaml, RDBMS client libraries (psql, mysql), gzip, bzip, termios, etc.
Situations that require better performance than is easily had in a higher level language: extension libraries, basically.

You didn’t know how much you loved C, did you?

C is portable, fast, has lots of quality libraries, good tool support, and is Freely available. Java is portable in theory, fast enough, has lots of quality libraries, excellent tool support, and is about to become truly available.

At this point, the pragmatic developer should be asking, what makes Java so much better than C that I should consider using it instead when I’m satisfied with what I have today? The answer is quite simple: malloc(3) and free(3), and more specifically, Java’s lack thereof.

You can take Java’s crippled OO foundation, enterprise scalability, vendor supported JEE containers and just throw it all out the window: I don’t care. Memory management is the reason to consider using Java over C right now.

Ruby: Just Because

Ruby is but one of many extremely productive and well designed high level languages: Python, Smalltalk, (Good) Perl, Scheme, Common Lisp, Groovy, Nice, etc. All amazing languages when you care about expressing logic to humans and, incidentally, to machines*.

If classes have a class, I’ll take it over Java. So why Ruby?

It hasn’t failed yet. I mean, Jython’s been around for a long time, seems to have lost steam, and the original author was hired by Microsoft for his work on IronPython. While I wouldn’t go so far as to call this failure, the momentum needed to build a strong community around the JVM seems to have waned.
Many other languages have already been smeared as kiddy scripting environments by Sun and the tech press.
The Perl guys are busy on their own VM.
There’s already interest in improving Ruby’s running environment in the Ruby community. The C based Ruby interpreter doesn’t seem to have the same level of prestige as, say, CPython or perl. It’s widely considered one of the slower dynamic language interpreters. Work on a new VM was recently merged to Ruby’s trunk but is not yet stable and won’t be for some time.
PHP doesn’t need the JVM: as far as I can tell, PHP is pretty much tied to C for all eternity. I’m not saying that’s a bad thing but the C under-pinnings are so clearly visible in the higher level language that putting the thing on Java almost seems like an insult.
Ruby is cool right now. I don’t pretend to understand the mechanics of cool but Ruby is it - for the time being, anyway. Whether that makes sense or not is irrelevant; with hype comes real and tangible benefits.

Now, as much as I like Ruby, I don’t think there’s anything insanely spectacular about the language that makes it better suited for a coup d’état on the JVM than many other languages. It just seems to be in the right place at the right time.

The other reason I’m focusing on Ruby is that I’m biased, lazy, selfish, and trying to create a bit of hype here. I’ve been using Ruby heavily for almost a year now and, as much as I hate to admit it, I’m beginning to hit a performance wall in some very specific cases. In addition, a few Java libraries have caught my eye whose Ruby or (C with Ruby bindings) analogs are considerably less developed.

I want to be clear that performance is not a problem across the board for me in Ruby. Quite the contrary, in fact. Performance has been good enough in all but a few corners of development. I’m also not talking about the ability to scale or anything that can be fixed with more hardware. I’m talking about stuff like image manipulation (graphing specifically), PDF generation, and flat file parsing. In these places, I could really use orders of magnitude increases in raw performance over what I can reasonably expect from Ruby today.

Solving the performance problem has meant dropping down into C, which isn’t all that bad but I’d personally be more comfortable dropping down into Java.

How this plays out in 2007

In Java land, people start taking Ruby seriously as an alternative to The Java Language on the JVM in a way that Jython, Groovy, and other dynlangs never accomplished. Not as a “scripting” or “glue” language but as a first class, general purpose programming language. A comfortable majority of components will still be written in Java for performance and broad reuse but Ruby will come in from the top and begin to steal away much of the application level logic on new projects - basically anything where readability and maintainability are more important than performance and reuse.

Ruby’s impact on the Java community will be almost entirely due to JRuby reaching increasing levels of bad-assedness. That is to say, Ruby’s adoption by Java heads on Java projects won’t have as much to do with the GPL and better packaging support as it does with the virtues of the Ruby language and the JRuby interpreter.

Suns increased financial support for, and clueful positioning of, the Ruby language in the Java ecosystem will also be critical. There’s all kinds of problems with this part, of course. Mentioning “Sun” and “clueful” in the same sentence generally requires a negation but there’s cause to believe that might be changing. A boy can dream, anyway.

While all this is playing out with the Java folks, the JVM will begin to be taken seriously as an alternative to CRuby in the Ruby community. Unlike in the Java world, this has less to do with JRuby and more to do with Java going GPL and the ready availability of the mainline JVM on Linux and BSD. You will begin to hear reports of Rails running on the JVM in both development and production environments with very little disruption to existing code bases. This will be followed by blog post after blog post extolling the virtues of being able to drop down into Java for performance critical pieces of code and how nifty JFreeChart is.

By the end of 2007, much of the Ruby web development community will consider the JVM to be a viable runtime environment. In Java land, Ruby on the JVM will be a growing sensation but it will take another year (2008) before Ruby is considered a peer to The Java Language.

On the other hand…

Things could be horribly different. Sun could marginalize Ruby the same way it has marginalized every other language that’s tried to run on the JVM in the past. ~~JRuby could poop out before reaching a satisfactory level of stability and performance~~ (see comments). The Ruby community could reject Java because of its historically poor reputation among hackers. The larger Java community could reject Ruby as a kiddy language.

One thing’s for sure: we’ll be hearing a lot about Ruby and Java in 2007.