6.3. Breaking It Down
That's a 30-minute tour through Ruby. I'm not saying that Ruby is the next great
language, but rather, that Ruby makes some of the hard things in Java easy. More
and more of the top independent consultants are looking for ways to make more
money working in Ruby, or other languages that are more dynamic. The Java
community is spending an amazing amount of money and brainpower on making
Java more dynamic. Dependency injection and aspect-oriented programming are
groundbreaking ideas for Java, and they are only now getting serious commercial
traction. For Java developers, these ideas represent better transparency and simpler
application development.
6.3.1. Collapsing Under the Weight of Abstraction?
My playtime in Ruby makes another, more powerful idea, clearer. As we stretch
Java in increasingly unnatural directions, there's a cost. AOP and dependency
injection are near-trivial exercises in Ruby, but they force Java developers to learn
new programming models, deal with XML, and introduce increasingly complex
syntax. With each new metaprogramming concept that we bake into Java, it's
looking more and more like all of that complexity is trying to drive us somewhere.
The net effect is to push Java further and further into the enterprise niche, and
make it less and less accessible to the average Joe. Contrast that situation with
Ruby, where dependency injection and AOP don't consume your focus; you're free
to apply those ideas in spots right where you need them.
I do think that Ruby, with Rails, is a near-ideal solution for that sweet spot that
we've pushed: a web-based frontend for a relational database. I've already said that
I'm using Ruby in a commercial application. My customer demanded productivity
and a price point that I couldn't achieve in any other way. I also still recommend
Java to many of my clients. They need complex frameworks that Ruby does not yet
support, or they depend on a core set of developers that have already been trained,
or they have so much legacy code in Java that change would be impractical.
In the next chapter, I'll make these arguments real. I'll show you how to build a
web-based application, from scratch, to access a relational database with a web

manufacturing plant. We effectively build a web user interface to manage a
complex domain model. We decided to build this application with a lightweight
Java stack of Spring, Hibernate, and Web Work. We moved pretty quickly, and
were pleased with our progress. We were proud of our accomplishments, because
we'd rewritten a one-year Microsoft application in four months with Java.
Na
turally, as we accumulated a bigger code base, coding began to take longer.
Over time, Dave's arguments nagged at my subconscious. Dave and my business
partner had the same conversations. As luck would have it, over the same week, we
tried building a part of the application in Rails. I banged out the model and
scaffolding in a couple of days. With his stronger HTML experience, Justin got
further than I did. He actually implemented the whole application in Rails in four
nights. The Rails version shocked us in another wayit was actually faster!
Justin Gehtland: A Ruby on Rails Case Study
Coauthor of Better, Faster, Lighter Java

Justin Gehtland is the co-founder of Relevance, a consulting/training
organization based in Durham, North Carolina. He's the coauthor of the
Jolt-winning book, Better, Faster, Lighter Java, and has been developing
applications of all sizes since the early 1990s. Over the last six years, he
has delivered products using Java, .NET, LAMP, and now, Ruby on
Rails.
You've recently
moved a Java
project to Ruby
on Rails. What
Java frameworks
did the
application use?
JG: The original stack was the usual suspects

strategies are right at the surface, and it's
easy to manage their life cycle. I was able to
max out the web server's ability to serve
pages. I literally couldn't get it to go any
faster.
Is Rails ready to
usurp Java?
JG: Ruby isn't going to outstrip Java on a
straight road. The JVM is tuned, and tuned,
and tuned again to optimize byte code
execution. But Ruby on Rails shines on the
turns. Its integrated stack, dynamic language,
and lack of a write/compile/test/deploy cycle
means it handles better. For this application,
it was like racing a Miata against a funny car
on a mountain road. The funny car has more
horsepower, but it just ends up driving
straight all the time.
What are the top
three things that
made Ruby so
much more
productive?
JG: I'd have to say that the dedication to
smart defaults is the primary benefit to Ruby
on Rails. Ben Galbraith has said it several
times, and I concur. Since Rails always lets
you override any of its defaults, you are
never in danger of getting stuck in a corner,
but for the most part, you can create an

often have the resources of your competition, you need to iterate fast. You can get
some leverage by working longer hours and cutting bureaucracy. If you can
generate an edge with technology, you've got to take that opportunity. In an
increasingly competitive global landscape, we'll all need to act more like start-ups.
If a framework makes you a mere 120% faster, you might be tempted to s
tay with a
safer language like Java. But if you can be 400% faster or more, I don't think you
can ignore the difference.
Remember, my premise is that Java is drifting away from its base. Most of us need
to build web applications on relational databases. Language issues are important,
but Java's drivers are so focused on hard-core enterprise problems that they're not
making any progress on this simple core problem. If Rails doesn't step into this
gap, something else will.
7.1.3. Some Numbers
I'm going to give you some performance and productivity numbers based on
experience. I recognize the numbers are imperfect, for a whole lot of reasons. In
some ways, the deck was stacked against Rails:
 The Ruby application implemented more customer requirements. By the
time Justin realized that his experience was important, he'd implemented
some features that never made it into the Java version.

Justin was a recognized expert in Java, but had never used Ruby in a project,
and had never used Rails. He wrote a Spring book, and he taught two
weekend sessions 16 times per year for Hibernate.
 The Rails framework has some design philosophies that are unfamiliar to
Java developers.
More importantly, some of the factors worked against Java in the implementation:
 The Java code was in no way fully tuned. The Java apps were much harder
to tune, so we didn't get as far. We'd only started to look into performance.
(The Ruby code was not fully tuned either, but its default implementation

classes/methods
62/549 55/126

Table 7-2 shows the performance numbers. They're probably a little more
controversial. I'm not trying to show that a Ruby application will always be faster
than a Java application. I'm just showing that in this case, Ruby is fast enough, and
it took almost no time or experience to get to this point.
Table 7-2. Difference in performance between untuned versions of a Java
application after we moved it to Ruby on Rails
Metric
(requests per second)
Java
Spring/Hibernate
Ruby
Rails
User scenario 1 (100 runs)
(no preexisting cache)
71.89 75.59
User scenario 1 (100 runs)
(with preexisting cache)
80.86 174.39
User scenario 2 (100 runs)
(no preexisting cache)
80.86 62.50
User scenario 2 (100 runs)
(with preexisting cache)
88.97 1,785.15

To be clear, in no way is Justin claiming that we've done everything possible to
tune the Java application. The point here is that tuning Rails to this level was