Ruby on Rails vs. Java part2

As mentioned in part 1 my task is implementing a mail and campaigning module. I started out with a pure Ruby on Rails application and moved to a mixed Java/Rails applications as Ruby’s communication libraries where just lacking mandatory features. I choose Java/Hibernate/Spring as the combination should provide me with most needed features through an easily extend- and configurable framework. What are my findings so far?

Lines of Code comparison

Ruby beats Java if you want an easy and fast web development framework, but as soon as you exit the web user interface niche it looses many of its advantages, still the lines-of-code count in java is around 4 to 6 times as large as Rails’s. Good for you if you’re paid by the line of code that you write, bad for you if you want to get things done.

Both frameworks rely on convention over configuration. As I wrote the Java application after the Rail’s one I had to configure Java to fit Rail’s way which resulted in lots of configuration which would be unnecessary if I’d written the application in Java from day one. Much of the simpler code (setter/getter for entity classes) were also auto-generated, so the LOC count should be looked at with a grain of salt.

Readability

The Java code is better readable which surprised me. While the Ruby code is more verbose and beatifuller the Java code tends to be longer, but overall simpler structured. It is a lot easier to debug and as my application will be deployed as a war file in an Java Enterprise container there’s lot of functionality (e.g. logging) which can easily be tapped. I had some very ugly functions dealing with mime parts in Ruby, those are a lot easier to read because of the static typing. Once again: while duck-typing is perfect for writting an application quick, static typing might come in handy if you want your application to be robust and long-lived.

Different approach to business object authority

Another difference (and source of increased Java LOCs) is the different approach to business object responsibility. That term describes who is responsible for declaring objects, their content and constraints. Rail’s ActiveRecord maps the a database table into a business object data type, a row into an object and a attribute into a class member. Each change in the data backend automatically changes your business objects. You can write automatic tests to check if your object model is still sufficient, but those tests are not run automatically when the application starts. Some definitions (i.e. constraints and relationships) are defined on business object level, so you have split definitions between the database and your object model.

With hibernate you write your business objects and add annotations (as you do with Rails) to describe how they are mapped to the database. But the final  authority lies at the application and the business objects. If there’s a database change no attribute appears or disappears automatically, but an exception is raised on application startup. You have to write more code, but you have all your data definitions (incl. tables, attributes, relations and constraints) in one single conceptional place. You can even generate your database layout from your object model.

The later approach is clearer for me (and does less automagic than the Rails approach), but there’s also a payoff: you’ll need many more lines of code to define your business objects. Also if you want to add a change you’ll have to change your data definitions in the database as well as in your application. This will never happen in Rails with it’s D-R-Y way (Dont Repeat Yourself). Choose ease and speed of writing code vs. IMHO more safer code as your database format and input is double checked.

The next part will talk about the differences in Rails and Java/Springs exception handling.

No related posts.