I'm doing an experiment, developing an enterprise application in Java and Ruby in parallel, trying to evaluate whether Ruby is enterprise ready, or Java must still remain my weapon of choice.

Monday, December 11, 2006

Java & Hibernate vs. Ruby & ActiveRecord

I did a lot of work on our data model the past two weeks, a little with Ruby, a little with Java, and back again. I thought I should share some insights regarding the different approaches they take towards modeling your data, and their pros and cons.

In general, with Java and Hibernate you’re supposed to start with the objects, then add the relational mappings. With Ruby on Rails you start with the relational database, and ActiveRecord builds the object model automatically from that.

It makes perfect sense that each language chose the path it did:

Thinking in Java, it’s natural to start with the objects, carefully design and code your classes and interfaces, then add some XML or annotations (I used the latter) almost as an afterthought, just to enable persistence. Books and manuals treat the need to map between objects to a relational DBMS as a sort of nuisance that you have to deal with.

In Ruby, it not as natural to start by defining properties and their data types for your classes, which may have led to the acceptance of the idea to start with SQL DDL (that’s all about properties and data types), then do the rest with some ruby magic.

After discussing the respective approaches with some Java people I noticed a common perception which I think is a gross mistake. They tend to think that when you design a data model you should only think in objects, and that considering the relational persistence layer doesn’t happen at this stage, and thus the Rails approach is problematic. I think that’s wrong. After all, you have to start by thinking in terms of entities and their relationships. You can call these tables, objects or whatnot, but that’s exactly what you need for a relational model. It’s possible though that it’s just me – I did a lot of work with RDBMSs in the past, so my thinking is effortlessly geared towards the relational representation.

When it comes to simplicity and speed of development, ActiveRecord beats Hibernate hands down. I built my model in Rails (i.e. effectively in SQL) first, which is faster (for me) than defining Java classes. Going deeper into ActiveRecord in order to add the various data access methods I’ll be needing, and writing unit tests for everything took me less than two days. The process I had to go through in Java to achieve the same result has been going on for over a week, and I’m not done yet. Also, there’s far less

Note that in my case that included learning ActiveRecord, and learning Hibernate, EJB 3.0 O/R mapping annotations, HQL, and the various Spring mechanisms that wrap the Hibernate stuff. Much more learning to do on the Java side. On the other hand, I’ve a lot of experience with SQL. For someone with no SQL experience, the Rails part may take longer.

In short, the Ruby part was fast and easy, and thus much more fun.

The thing that annoyed me most with ActiveRecord are related to its lack of expressiveness: just by looking at the code, it’s impossible to tell what data members are hiding in my model - you have to look at the DB or migrations. Another issue is the conventions-based magic. The conventions for DB column names sure make things easy, but are rather annoying if you’re used to different conventions...

As usual, there’s a word of caution: all I did so far was very basic – I defined the model and added some rather na├»ve access methods. Rails tends to shine when you just start things up. Java and Hibernate may look better when my code gets more complicated.

For a more comprehensive comparison one (though outdated on some points) take a look at Patrick Peak’s Showdown article.

16 comments:

Guillaume said...

Rails tends to shine when you just start things up. Java and Hibernate may look better when my code gets more complicated.

I see lots of people saying the same thing. Rails is great but it might not be as good later. I can't wait to see the results 6 months or one year down the line when people who used to have a fair amount of Java experience and switched to Ruby now have large systems in Ruby to maintain.

Right now saying Rails is going to be better or Java will be better down the line is speculation at best but soon enough we'll have real empirical results so please keep us posted on how your projects fair.

Thanks.

Adam Bien said...

There are two modes:
-design the objects
-design the database
Doing both in parallel is not very efficient. I never created the OR-Layer in Java from scratch in case the database already existed. Either you can use tools like middlegen or even free and opensource IDEs can provide this for you. In Nebeans 5.5/6 just create a datasource right-click on your project and choose "Create entities from existing databases" and all JPA-Entities will be created (with relations) etc. for you.

The cool story here: you can test your persistence with an usual unit-test - outside the server.

Harel Malka said...

Did you find out how the two frameworks compare in relation to performance under heavy load?
Has anyone done such a benchmark?

Harel

Paul Browne - Technology in Plain English said...

I'm glad to see a 'hard edged' comparision between the two approaches.

Often we hear the 'Ruby is faster' mantra, without anything to back it up.

At least this time you have some figures so that we can compare the two!

quasistatic said...

To be completely fair, you really shouldn't be comparing a framework like Rails against Java/Hibernate/Spring straight up. A fairer comparison would be Ruby on Rails vs. Groovy on Grails. Grails uses Hibernate & Spring under the hood, but also applies the convention over configuration aspect that Rails gives you. I would think this would give you a better look at the efficiencies of the two. There are still some major differences as well.

-Jesse
Refactr LLC

Brian said...

Sounds to me like it's easier for someone with a database background to go the Ruby route and easier for someone with a OOA/OOD/OOP background to go the Java route. This mainly applies in the area of the relationships that exist between the entities I think. However, this seems to apply when designing your data model to begin with and not necessarily when it comes down to actually building the thing. The reason for this is that once you have your model done in Java, you do have to have an understanding of the database model that will be created via the hibernate tags. You have to know what a one-to-many, many-to-many, etc. relationships will look like. I'm a Java guy myself and have dabbled in Rails. Thanks for the article... I'll have to give it a go at some point to find out for myself. :)

Anonymous said...

I always create database first and generate Hibernate objects later.

Elad said...

Quasistatic -
As far as I can tell, Grooby and Grails are meant as Ruby and Rails versions for the Java world. However, I just can't see the point - if Ruby's a great language and Rails is a great framework, what's the point in using a Java-version?
My point in this experiment is to test whether a Java alternative is ready for prime time in the enterprise.
Of course, that's just my POV. Not everybody is as eager to ditch Java as I am, so there's a place for a phased approach, i.e. Grooby. Nevertheless, I personally don't think that there's any advantage in such an approach.

Elad said...

Harel,

I haven't done any performance benchmarks so far. I'm simply not in that point in the project.
Eventually I'm gonna use LoadRunner on this, and I'm definitely going to publicize the results. That's probably months from now though.

Anonymous said...

I don't think data modeling has anything to do with programming languages or technologies, it's about expressing business rules which are the same regarless of how you implement them.

Richard said...

Ive been using Ruby on Rails extensively for a startup company. The true beauty of ActiveRecord is that it is easy to get going in AND it is still easy for complex tables. It is one of the rare instances I have seen in software where this is true. This is the oposite of VisualBasic where it is easy to get started and then goes down hill from there.

The other issue is performace. The performance of developers is waaaaay higher in Rails, but the execution performance is not good. This leaves one with the tradeoff of getting to code complete faster, and surviving as a startup, or having to use more servers when success comes and you need to scale up. On the other hand, Ruby is increasing in performance about as fast as our company is growing. It appears that Ruby 1.9 will be 2.5 X faster, greatly mittigating the execution speed issues. Also server cost is dropping so I choose Ruby.

jjnevis said...

I been coding java front ends on Oracle DBs for some time now (8 years or so). I recently started a new "greenfield" project and decided to try out RoR and was utterly astonished at how easy it was to pick up, not to mention fun. Active record is a big part of why it's so enjoyable. I'm not sure I can face coding java again, it's just so boring - compare any java example with ruby example on the web (web services, rmi, persistence (this discussion) etc). I get the feeling java is serious, ruby/rails is fun, reminds me a bit of PS3 v Wii!

Elad said...

jjnevis,
I share your feeling - RoR, and Ruby in general IS fun compared with Java.

david said...

Take a look at the annotate_models plugin for rails. It will unpack the domain model expressed in your migration into your model object as comments at the top of the file.

Mangal said...

Are we here for fun??? ROR is fun.... are we on holidays??? I am working with java from more than 4yr... can you think ROR with 10 millions of records are there and inserting more then 500 records with in a fraction of second in threading environment... could ROR support you on this situation??? Definitely NOT

nilspreusker said...

Elad, first of all thanks for sharing this! I think it is simply a question of what framework makes more sense for specific situations. All Java frustration and Rails enthusiasm aside, sometimes Java might be the best choice because it scales better, sometimes Rails might be better because it lets you focus on the important things and helps you to be up and running faster. As some previous comments suggest, it should be very interesting to see how the project evolved and what you can say about the differences and advantages or disadvantages of Hibernate and Active Record now, two years after you first started.

Thanks!