Java Frameworks War: Spring and Hibernate

Question

My developers are waging a civil war. In one camp, they've embraced Hibernate and Spring. In the other camp, they've denounced frameworks - they're considering Hibernate though.

The question is: Are there any nasty surprises, weaknesses or pit-falls that newbie Hibernate-Spring converts are likely to stumble on?

---

PS: We've a DAO library that's not very sophisticated. I doubt that it has Hibernate's richness, but it's reaching some sort of maturity (i.e. it's not been changed in the last few projects it's included).

Answer 1

They've denounced frameworks?

That's nuts. If you don't use an off-the-shelf framework, then you create your own. It's still a framework.

Answer 2

I haven't worked much with Java but I did work in large groups of Java developers. The impression I've got was that Spring is OK. But everybody was upset at Hibernate. Half the team if asked "If you could change one thing, what would you change?" and they'd say "Get rid of Hibernate.". When I started to learn Hibernate it struck me at amazingly complex, but I didn't learn enough (thankfully I've moved along) to know if the complexity was justified or not (maybe it was require to solve some complex problems).

The team got rid of Spring in favor of Guice, but that was more like a political change, at least from my point of view and other developers I've talked to.

Answer 3

Frameworks are not evil. even the Java SDK is a framework.

What they probably fight is framework proliferation. You shouldn't bring a framework to a project just for the kick of it, it should bring consistent value in a reasonable time. Every framework requires a learning curve, but should reward you with increased productivity and features later on.

If you struggle with code that is hard to debug because of inconsistent database usage, complicated cache mechanisms, or a myriad of other reasons. Hibernate will add great value. apart from the learning curve (which took about 1 month of practical work for me) there weren't any pitfalls, provided you have someone around to explain the basics for you.

Answer 4

Hibernate has quirks to be sure but that is because the problem it is trying to solve is complex. Every time someone complains about Hibernate I remind them of all of the boring DAO code that they would have to maintain if they weren't using it.

A few tips:

• Hibernate is no substitute for a good database design. Hibernate schemas are OK but you will have to tweak them occasionally
• Eventually you are going to have to understand how Hibernate lazy loads classes and how that affects things. Hibernate modifies the Java bytecode and you will need to delve into the depths sooner or later if only to explain why object links are null.
• Use annotations if you can.
• Take the time to learn the Hibernate performance tuning techniques, it will save you in the long run.

Answer 5

I've done a lot of Spring/Hibernate development. Over time the way people used both in combination has changed a bit. The original HibernateTemplate approach has proved to be difficult to debug since it swallows and wraps otherwise useful exceptions; talk to the Hiberante API directly!

Please keep looking at the generated SQL (configure your development logging to show SQL). Having an abstraction layer to the database doesn't mean you don't have to think in SQL anymore; you won't get good performance if you otherwise.

Consider the project. I've choosen iBatis over Hibernate on several occasions where we had stringent performance requirements, complex legacy schemas or good DBa's capable of writing excellent SQL.

Answer 6

@slim - I am with you again this morning.

It sounds like a classic case of Not Invented Here Syndrome. If they aren't keen on spring, they should consider other options rather than rolling their own framework (whether they acknowledge doing it or not). Guice comes to mind as an possibility. Also picocontainer. There are others out there, depending on what you need.

Answer 7

If you have a fairly complex database, Hibernate may not be for you. At work we have a fairly complex database with lots of data, and Hibernate doesn't really work for us. We've started using iBATIS instead. However, I know a lot of development shops who use Hibernate successfully - and it does do a lot of grunt work for you - so it's worth considering.

Spring is a good tool if you know how to use it properly.

I would say that frameworks are definitely a good thing - like others have pointed out, you don't want to reinvent the wheel. Spring contains a lot of modules which will mean you won't have to write so much code. Don't succumb to the "Not Invented Here" syndrome!

Answer 8

As for Hibernate: a very good tool for application which deals with a rapidly changing database schema, a large amount of tables, do lots of simple CRUD operations. Reports with complex queries involved are rather less well handled. But in these case I prefer mixing in JDBC or native queries. So, for a short answer: I do think time spent learning Hibernate is a good investment (they say it is compliant with EJB3.0 and JPA standards, also, but that didn't come into the equation when I evaluated it for my personal use).

As for Spring... see The Bile Blog :)

Remember: frameworks are not silver bullets, but you should not reinvent the wheel either.

Answer 9

This is one thing (I could remember) that I fell into when I was in my Hibernate days. When you delete (several) child objects from a collection (in a parent entity) and then add new entities to the same collection in one transaction without flushing in the middle, Hibernate will do "insert" before "delete". If the child table has a unique constraint in one of its columns, and you are expecting that you would not violate it since you have already deleted some data before (just like I was), then get ready to be frustrated. Hibernate forum suggests:

1. It was a DB design flaw, redesign;
2. flush (or commit if you will) in between the deletes and inserts;

I couldn't do both, and end up tweaking the Hibernate source and recompiling. It was only 1 line of code. But the effort to find that one line was equal to approximately 27 cups of coffee and 3 sleepless nights.

This is just one example of problems and quirks you might end up when using Hibernate with no real expert on your team (expert: someone with adequate knowledge about the philosophy and internal working of Hibernate). Your problem, solution, litre of coffee, and sleepless night count may vary. But you get the idea.

Answer 10

I find it really helps to use well-known frameworks such as Hibernate because it fits your code into a specific mold, or a way of thinking. Meaning, since you're using Hibernate, you write code a certain way, and most if not all developers who know Hibernate will be able to follow your line of thinking quite easily.

There's a downside to this, of course. Before you become a hot shot Hibernate developer, you're going to find that you're trying to fit a square into a circular hole. You KNOW what you want to do, and how you were supposed to do it before Hibernate came into the picture, but finding the Hibernate way of doing it may take... quite a bit of time.

Still, for companies that frequently hire consultants (who need to understand a lot of source code in a short amount of time) or where the developers sign on and quit frequently, or where you just don't want to bet that your key developers will stay forever and never change jobs -- Hibernate and other standard frameworks are a pretty good idea I think.

/Ace

Answer 11

I have always found Hibernate to be a bit complex and hard to learn. But as JPA (Java Persistence API) and EJB (Enterprise Java Beans) 3.0 has existed for a while things have gotten a lot easier, I much prefer annotating my classes to create mappings via JavaDoc or XML. Check out the support in Hibernate. The added bonus is that it is possible (but not effortless) to change the database framework later on if needed. I have used OpenJPA with great results.

Lately I have been using JCR (Java Content Repository) more and more. I love the way that my modules can share a single data storage and that I can let the structure and properties evolve. I find it a lot easier working with nodes and properties rather that mapping my objects to a database. A good implementation is Jackrabbit.

As for Spring, it has a lot of features I like, but the amount of XML needed to configure means I will never use it. Instead I utilize Guice and absolutely love it.

To roundup, I would show your doubting developers how Hibernate will make their life easier. As for Spring I would seriously check if Guice is a viable alternative and then try to show how Spring/Guice makes development better and easier.

Answer 12

Spring and Hibernate definitely make life easier. Getting started with them might be a little time-consuming at the beginning, but you'll certainly benefit from it later. Now the XML is being replaced by annotations, you don't need to type hundreds of lines of XML either.

You may want to consider AppFuse to reduce your learning-curve: generate an application, study and adapt it, and off you go.

Answer 13

Lazy loading is the big gotcha in MVC applications that use Hibernate for their persistence framework. You load the object in the controller and pass it to the JSP view. Some or all of the members of the class are proxied and everything blows up because you Hibernate session was closed when the controller completed.

You will need to read the Open Session in View article to understand the problem and get a solution. If you are using Spring the this blog article describes the Spring solution to the open session in view issue.

Answer 14

Spring and Hibernate are frameworks that are tricky to master. It may not be a good idea to use them in projects with tight deadlines while you're still trying to figure out the frameworks.

The benefits of the frameworks is basically to try to provide a platform to allow for consistent codes to be products. From experience, you'd be well advised to have developers experienced with the frameworks setting in place best practices.

Depending on the design of your application and/or database, there are also quirks that you'll need to circumvent to ensure that the frameworks do not hinder performance.

Answer 15

I've used Hibernate a number of times in the past. Each time I've run into edge cases where determining the syntax devolved into a scavenger hunt through the documentation, Google, and old versions. It is a powerful tool but poorly documented (last I looked).

As for Spring, just about every job I've interviewed for or looked at in the past few years involved Spring, it's really become the de-facto standard for Java/web. Using it will help your developers be more marketable in the future, and it'll help you as you'll have a large pool of people who'll understand your application.

Writing your own framework is tempting, educational, and fun. Not so great on results.

Answer 16

I have to agree with many posts on this one. I've used both, extensively, in a variety of settings. If I could undo a design decision it would be to have used Hibernate. We actually budgeted a release in one of our products to swap Hibernate for iBatis and Spring-JDBC for a best-of-all-worlds approach. I can have a new developer get up to speed using Spring-JDBC, Spring-MVC, Spring-Ioc, and iBatis faster than if I just tasked them with Hibernate.

Hibernate is just too complicated for this KISS developer. And heaven help you with hibernate if your DBA sees the generated SQL the database sees and sends you back with optimized versions.

Answer 17

In my opinion, the biggest advantage of Spring is that it encourages and enables better development practices, in particular loose coupling, testing, and more interfaces. Hibernate without Spring can be really painful, but the two together are very useful.

Retrofitting an existing project to any framework is going to be painful, but the refactoring process often has serious benefits for long-term maintainability.

Answer 18

The top answer mentions that Hibernate is poorly documented. I agree that the online reference manual could be more complete. However, a book written by Hibernate's authors, 'Java persistence with Hibernate' is a must-read for every Hibernate user and very complete.