It's the ultimate JVM Web Framework Smackdown! Three will enter the cage. Only one will exit the victor. Will it be JRuby on Rails? Groovy on Grails? Or Helma?
Before the advent of Ruby on Rails, many Web developers worked with Perl or vanilla PHP. Perl’s legacy dated back to the earliest dynamic Web sites. In heady days, the “Perl Mongers” were active proponents and evangelists, and the community nurtured and maintained a vast repository of contributed code. PHP was simple to learn, a snap to deploy and host on virtually any platform, and thus quickly earned a devout following. Indeed, both languages grew popular because it was easy to start an application. However, as Perl and PHP applications grew, developers inevitably became tangled in a mess of code.
Other developers eschewed scripting languages and opted for more heavyweight Web frameworks, especially those written in Java. Applications written in Java were bullet-proof and backed by a rich set of libraries, but were far from perfect, too. Java frameworks exacted a high price, miring developers in the pits of XML hell. While the Java frameworks scaled well, the initial inertia left many Java web developers jealous of the rapid, early progress Perl and PHP developers enjoyed.
Ruby on Rails, to a large degree, delivered the best of both worlds. Rails featured a well-thought out organization that guided developers toward a clean MVC design, and through a philosophy of Convention over configuration, developing new applications was only marginally more difficult than with straight PHP. Web developers, it seemed, could finally have it both ways.
But the story does not end with the advent of Rails. More and more sites began to use Rails, but as several endeavors became successful, developers also ran into new challenges. Twitter gained notoriety when the company moved part of its architecture to Scala. And, despite the benefits of Rails, many developers have begun to miss the wealth of libraries and tools commonly found with Java.
The Sample Application: PenguinMusic
To test JRoR, Grails, and Helma, let’s build a music site from scratch with each framework. The sample site, PenguinMusic (shown), allows users to browse songs ordered by popularity, view details about an artist and album, and leave comments if logged in to the application. The application also handles user registration.
While this sample application does not take advantage of all the bells and whistles each framework offers, it does focus on a core subset of features that virtually every website must provide, including database interaction, user authentication, and form handling. The sample code also looks at automated testing and site administration to some extent. However, no attempt is made to build facilities for Ajax or address performance. Not every site needs Ajax support, and all these frameworks have at least adequate performance for the bulk of Web applications. The focus here is the ease of launching a new application.
Each of the three frameworks ships with an embedded databases, but odds are MySQL is your choice for a production database, so that’s what’s demonstrated here. However, since all the candidate frameworks rely on JDBC, you can interact with just about any major database engine.
If you would lke to follow along, you can download the source code for each implementation. Additionally, there are some helpful scripts to load test data for each of the database setups.
JRuby on Rails: The Classic, Now Playing at Your Local JVM
If you want the benefit of a Ruby on Rails-like framework for the JVM, one obvious option is, well, Ruby on Rails. The JRuby team has been focused on Rails from the beginning, and with JRuby 1.0, the team finally achieved full Rails compatibility. Performance was terrible initially, but the developers have done a great deal of work since and more recent versions are quite fast.
The source code for the JRuby on Rails implementation of PenginMusic can be downloaded here.
Getting Started with Rails, the JRuby Way
Installing JRuby on Rails is only a little more complicated than installing traditional Rails. You must download Gems and install it with JRuby and install the requisite libraries. The command to use is:
$ jruby -S gem install mongrel activerecord-jdbcmysql-adapter rails
jruby -S rails jrorPM -d mysql creates a new application named
jrorPM based on MySQL. After the initial code generation, your first task is to edit
config/database.yml to match your database configuration. In particular, you must specify
jdbcmysql as the adapter.
# Warning: The database defined as "test" will be erased and
# re-generated from your development database when you run "rake".
# Do not set this db to the same as development or production.
Once the database has been configured,
jruby -S rake db:create:all initializes the database, and
jruby script/server starts the application.
Rails Models and Migrations
One of the hallmarks of Rails implementations is that the structure of the data model lives solely in the database. This avoids any repetition of logic, a core tenet of Rails’s Don’t Repeat Yourself (DRY) philosophy. However, most of the validation logic lives in the Ruby models. As a result, one must switch between the database table and the Ruby class to get a complete picture of the model. However, this is a relatively minor hindrance, as the strong connection between the database and the model class is one of Rails’s greatest strengths.
Once upon a time, Rails developers used SQL to create models, but the practice has gradually fallen out of favor. Today, developers are encouraged to use migrations instead. Migrations are Ruby scripts that create or update a database schema. A migration is also database-independent and is fairly straightforward to use. Migrations also offer an important advantage: versioning. Historically, tying a database version to a code version has been problematic. Migrations offer a solution.
However, migrations can also be brittle. If there is a problem in any of the migration scripts, the database can become stuck in an unusable state, forcing you to resort to SQL to fix the problem anyway. Migrations also are noticeably lacking in features. For instance, foreign key constraints are not available without a plugin.
SQL does provide fine-grained control and is an option with Rails, although you may be heckled by some Rails fanatics if you choose to use it. Here, let’s stick with migrations since they are the more conventional approach.
generate script creates new models and other components from the command line. Specify
model as the first argument if you just want to create the required model class. More often than not, though, you’ll want to specify
scaffold instead to generate a model and complementary administrative pages to create, edit, and delete records. The second argument to
generate is your model name, and the remaining arguments are
name:type pairs, one pair per field. (You can actually omit all of the fields and manually edit the migration script yourself if you prefer.)
To generate the code for the
Song model and scaffold, the command is:
$ jruby script/generate scaffold song name:string album_id:integer \
track_num:integer playlist_url:string duration_in_seconds:string \
The command creates a file named db/migrate/*_create_songs.rb (the * is a serialized value that orders the migrations in a sequence) with the following contents:
class CreateSongs < ActiveRecord::Migration
create_table :songs do |t|
Although you can use this migration as-is, let’s modify the code to improve the database representation. Let’s make
name required fields and let’s assign a default value for
num_downloads. This requires changes to three lines:
t.string :name, :null=>false
t.integer :album_id, :null=>false
t.integer :num_downloads, :default=>0
The process is repeated for the other models, followed by a database update:
$ jruby script/generate scaffold album artist_id:integer genre_id:integer \
title:string public_id:string url:string album_cover_url:string \
album_cover_name:string price:float blurb:text
$ jruby script/generate scaffold artist name:string url:string
$ jruby script/generate scaffold genre name:string code:string
$ jruby script/generate scaffold user username:string \
password:string email:string admin:boolean
$ jruby script/generate scaffold comment user_id:integer album_id:integer \
title:string body:text post_date:datetime
$ jruby -S rake db:migrate
As a final step, the models must be tied together. This is done through the
belongs_to, and the concisely named
As an example, here is the model class for
class Album < ActiveRecord::Base