JRuby - Web 2.0 in the Enterprise Java world

by Paul Browne

On a recent project , the choice was between Enterprise Java (using frameworks such as DWR and Struts) , or Oracle Forms. The newest latest Java technology , versus a 15 year old technology that Oracle is comitted to phasing out (and moving to ADF / Oracle fusion). No contest , you think , until you hear that the decision was made (and rightly so) to us Oracle Forms.

'What?!' I hear you say - how could this happen? The project in question was fairly simple - get information and store it in a database. The problem is , despite being mainstream for the last 6 years, there is no standard, easy 'drag and drop' method of doing these applications in Java. C# does it in Visual Studio. Oracle does it with Forms. With Java (and despite having doing 10 or so of these projects), there is still too much plumbing that the developer needs to know.

I'm expecting a deluge of 'have you tried project X' on this post. And yes, I expect that an Eclipse based tool will probably fill the gap. But for these simple applications , there is no standard way of doing this (standard being a solution that dominates the market in the way Struts did the Web App framework space, until recently). But we've been waiting 6 long years!

ruby on rails logo

All of which brings me to Ruby. Ruby on Rails' sweet spot is exactly these kind of simple, ajax enabled , no frills 'get info from web and store it on database' applications. Enterprise Java's sweet spot is the heavy lifting workflow , Rules , Calculations, Integration with Legacy and other systems , web services and basically anything to do with Business logic. The two are a perfect complement to each other, which is why the news that JRuby now runs Ruby on Rails is especially interesting.

JRuby is a version of Ruby that runs in the Standard Java Virtual Machine (JVM). It means that (1) You don't have to install Ruby, which might meet resistance in a corporate environment. It also means (2) that all the methods you have available in Java you have available in Ruby. The O'Reilly Ruby site and this Javaworld Article are good places to start learning more about Ruby and linking it into Java. Fellow O'Reilly Blogger Steve Anglin also has more information about the latest JRuby release.

More on Technology in plain English


2006-07-20 06:55:17
From what I understand, NetBeans may have that kind of web form development for JSF.
Rob Breidecker
2006-07-20 07:10:26
Excellent summary of the state of Java frameworks. I have to agree that JRuby is a serious contender for that Java "sweetspot".
Tim O'Brien
2006-07-20 11:26:57
JRuby doesn't *really* run Rails yet. If you try to install it and use it for anything other than the demos, you are going to experience much pain. It is closer, but not there just yet.
lazy programmer
2006-07-21 07:58:03
Personally wouldn't want a 'drag and drop' method. All that mouse movement still sounds too much like hard work. Surely, with the ideal tool for creating bog standard CRUD apps for pre-existing databases, one would enter the db connection properties in a file and type:

$ ant

Haven't looked to see if this one runs outside of an IDE yet with just an ant file, but from the demo it looks like it might be just what you want.


Charles Oliver Nutter
2006-07-21 22:44:46
Tim O: Although you're right, we don't officially support Rails yet, we haven't gotten many specific complaint about things not working. I'm going straight through Agile Web Development With Rails right now to see how far I get without hitting a snag...and it's going fairly well.
2006-07-24 03:13:20
If the project needs to "get information and store it in a database", then why would any 'frameworks' be needed in addition to the base JEE APIs? Would a simple JSP not suffice? The SQL tag library (JSTL) perhaps if you are feeling a little fancy? I haven't used JSF much, but experimenting with JSF/Creator feels very easy and similar to the C#/.Net approach. JEE *can* and *easily* scales down to simple projects too. Especially with an out-of-the-box installation of Netbeans these days. Frameworks are *not* a requirement and rarely add anything truely useful beyond the standard JSP/Servlet APIs for small-to-medium web projects.
John Latham
2006-07-24 07:40:37
I don't understand the use cases for RoR in JRuby.

Why not (for instance) run RoR & your servlet engine separately behind Apache, and use JkUnmount to pass specific URLs (e.g. /ror/) to RoR. This is what we do with PHP apps, works much more cleanly that trying to use the "PHP servlet".

If "resistance in a corporate environment" is a problem, you shouldn't be running RoR in the first place.

You point about "all the methods you have available in Java you have available in Ruby" is probably valid, but not sure it's worth the costs of entangling your servlet engine with RoR. Surely the point of RoR is to get away from Java.

As for "drag and drop" as a requirement, is that for programmers without fingers? For me the keyboard works just fine ;-)

Paul Browne
2006-07-25 00:23:42

I just want to make doing simple websites ... simple!

The Apache setup you mention is a good migration path, but am happy to stick with Java if it could give me what I want (a quicker way to websites).


John Latham
2006-07-25 01:28:42

"I just want to make doing simple websites ... simple!"

Me too!

My particular interest is in commodity hosting. Web hosting has become steadily commoditised but is still fragmented.

If I want LAMP(hp)/LAMR(ails) that's supercheap ($5/month shared). If I want LAMJ(ava), that's just cheap ($30/month VPS). If I want all of it, I'm mostly forced to pick the highest common denominator (LAMJ) and fudge the PHP/RoR, or go dedicated ($$$).

I hope we will see commodity providers supporting all of these free(ish) stacks.

This will put pressure on IT depts to follow (business will ask "why can't you do something that I can buy for $30/month?").

Then your problem is solved.

btw, the other advantage of running Rails/PHP outside of the servlet container is availability and (perceived) security. We have a cluster running PHP (for web CMS and phpBB) and Tomcat (for Confluence/JIRA). Upgrades to the Java apps require Tomcat reboots, which don't affect availability of the main web site. From a security point of view, I also feel more comfortable keeping the "script monkey" code (joke) outside of my JVM.

John Latham
2006-07-25 01:41:50
"highest common denominator". WTF? Note to self: avoid the maths metaphors.
Jon Craven
2006-07-31 08:34:03
I agree with "Confused" above--in the Java space you have a lot of press time given over to the big solutions: EJB, Struts, and all that. We all know by now that EJB is overkill unless you need distributed transactions, but I don't think the community has grasped that Struts et al. are overkill for simple CRUD apps. JSPs with JSTL are plenty if you don't need to do anything fancy with the data. And if your developments do grow, you at least know that with Java you can scale to whatever size you may need.