Imagine that you are a Java developer, and you’re about to start your next big project. You need to make the fundamental decisions that will stick with you for the rest of the project. You want to pick the best object-oriented abstraction of your flexible data model because you do not want to deal with plain SQL. You want to support all kinds of data, and ideally, support all sorts of databases.

The obvious answer is to just use Hibernate, right? 90% of Java developers would agree with you, but does that make it the right decision?

Let’s take a look at what can go wrong if you blindly use Hibernate just because it’s the accepted standard.

Consider Monica, a Java developer. Monica has recently been promoted to the role of architect and is now responsible for laying out the technology stack for a new product at her company. She knows that in the Java world there is only one good tool for handling database communication: Hibernate. Hibernate is a well known and supported JPA standard. However, it is always a good idea to check a few things before starting a project. Fortunately, her colleague, Ben, knows the right guy.

Hibernate Sounds Like A Silver Bullet

4 Years Ago

Ben - Hello Monica, I’d like to introduce John. He’s a Hibernate expert, and he’s going to help you.

Monica - Hey John, glad you found some time for me. So, we are building our Next Big Thing, you know. We are planning on becoming the next Facebook or Google. Busy days. It’s going to be huge. Absolutely fantastic! Everybody is so excited! I’ve been promoted to the role of an architect, so now I have to select the stack we will be using. The only missing part is persistence …

John - Hibernate!

Monica - Yes! Exactly! Just what I was thinking! It seems like a perfect match and the real deal for us. A true enterprise solution for a true enterprise problem, proven by the market and with a long history. I’ve heard so many positive experiences with it. However, I have an issue with one of our teammates; he is totally against it. He knows a lot about databases, and he’s afraid of adding another layer between our application and the database. He is super smart, and I need some really good arguments to convince him this is a good decision. Can you help me with that?

John - Of course! I will be glad to. Hibernate is, indeed, an outstanding tool. It’s widely used in big, true enterprise solutions, like banks. You can’t go wrong with it. Think persistence: Pick Hibernate. If you are writing in Java, this is absolutely the right choice, plus you have ports for other languages. See how many job descriptions require it!

Monica - I absolutely agree! I have the same feelings about it. In a previous project, we were using mostly SQL via plain old JDBC. Ridiculous! I know! But, here’s the thing: We have really smart SQL guys in the team and when they saw SQL generated by Hibernate they got nervous. It seemed ugly and unreadable; will this be a problem in future?

John - Look. DBA guys have a different perspective. They are afraid of Hibernate because it seems to replace their role in the project. Moreover, databases have built-in query optimizers so you don’t need to worry how those queries will actually look. The database will optimize it for you. It’s all about rapid development, which SQL can’t do.

Monica - Really?! No longer dealing with SQL? Amazing! Last time a DBA spent weeks trying to optimize some queries. Weeks! Oh, I feel so embarrassed telling you this, but did you know that we were using … stored procedures (laughing). Oh, it was such a mess. Can you believe the project is still using it? I feel so sorry for people out there. They still have to write this tedious code over and over again. I wonder if it’s still a Java or SQL project?

John - That’s exactly the difference between an object-oriented approach and the relational one. It’s a so-called object-oriented impedance mismatch. Hibernate can close this gap. Developers can focus on building business logic. Push features make stakeholders and the entire management happy. Do the things that matter most: Business! Lots of boilerplate code will disappear, and you’ll have a magical, invisible, but reliable, connection between the logic and the data.

Monica - Mutual cooperation. Full synergy. Like the database was part of the language from the very beginning. I am so happy I get to be a leader of this technological leap of faith. It’s like warp speed in the software trek.

John - Yep! You’ve got it!

Monica - Oh gosh, I’m so excited! Thank you, John! I’m ready!

Hibernate

Hibernate isn’t a silver bullet. Don’t treat it as your default database solution.

Growing Pains With Non-Flexible Solutions

3 Years Ago

Monica - Hey John, remember the project we spoke about last year?

John - Sure. How’s it going?

Monica - We are going to production soon. Everything is fine, but some questions have popped up.

John - Sure, hit me.

Monica - Well, we can no longer generate our database schema from scratch. What’s the best way to support schema changes without losing data?

John - Well, first, Hibernate isn’t intended to be used as production migration tool. Use something like FlywayDB or Liquibase. It’s pretty simple. You write down migration scripts, then you update the entity model along with the Hibernate mappings, so it keeps in sync with the actual database structure.

Monica - Hmm, I see. We were using just plain SQL migration in the previous project.

John - That’s fine too. As long as you keep the entity model and schema in sync, do it how you like.

Monica - I see. There’s another thing. We’re always struggling with lazy/eager fetching problems. At one point, we decided to do everything eagerly, but it seems suboptimal, and besides, sometimes it’s not possible to access some fields because there is no session, or something like that. Is that normal?

John - You need to learn more about Hibernate. Mapping from the database is not straightforward. Basically, there are multiple ways of doing it. You just need to pick a way that works for you. Lazy fetching gives you the ability to load those objects on demand, but you need to operate within an active session.

Monica - We’re still struggling with which database engine to use for the final deployment. I thought Hibernate was portable, but we have some native queries that use some MS SQL magic, and we’d actually like to go with MySQL in the production.

John - Hibernate gives you flexibility as long as you are using detached criteria or HQL; any native queries will just bind your solution to the database.

Monica - Seems like we have to stick to the MS SQL then. Last question: My teammate said that there is no “limit” keyword in HQL. I thought he was joking, but I couldn’t find it either. Sorry for the stupid question…

John - Indeed, there is no “limit” keyword in HQL. You can control this via query object since it’s database-vendor specific.

Monica - Seems weird that all the other elements are in HQL. Nevermind. Thanks for your time!

We’re Now Hacking Together Solutions In SQL Again

2 Years Ago

Monica - John, at the beginning we weren’t going to deal with SQL, but now it seems like we have to. Our needs are growing, and it seems like there’s no way around it. It feels wrong, but we’ve started using SQL again on a daily basis.

John - Well, it’s not wrong. You didn’t have to focus on the database at the very beginning. However, as the project grows, it’s good to use SQL and work on the performance optimization.

Monica - Sometimes we spend days looking for errors. It seems like we have to analyze Hibernate-generated SQL because we have no idea why it’s not working as expected and it’s producing unexpected results. We hit some problems that are well known in the Hibernate bug tracker. Additionally, it’s hard to write proper migrations while keeping the entity model in sync. It’s time-consuming since we need to learn a lot about Hibernate internals and predict how it’ll work.

John - There’s always a learning curve. You don’t have to write much, but you do need to know how it works.

Monica - Working with bigger datasets is also annoying. Recently, we did a massive import to the database, and it was painfully slow. Then we found out that we had to clear the session to make it faster. Even so, it’s still significantly slower, so we decided to rewrite it as plain SQL statements. What’s funny is that writing plain SQL was actually the fastest way of doing it, so we decided to do it as our last option.

John - Import is not an object-oriented process. Hibernate focuses on object-oriented design. Remember that you can always use native queries.

Monica - Can you help me understand how Hibernate cache works? I just don’t get it. There are some first/second level caches. What is this all about?

John - Sure. It’s a so-called transaction-level cache of persistent data. It’s possible to configure a cluster or JVM-level cache on a class-by-class and collection-by-collection basis. You can even plug in a clustered cache. But remember that caches aren’t aware of any changes made to the persistent store by another application. They can, however, be configured to delete expired cached data regularly.

Monica - Sorry, think I’m having a bad day. Can you explain this a bit more?

John - Sure. Whenever you pass an object to save, update, saveOrUpdate, or retrieve it via load, get, list, iterate or scroll, that object is added to the internal cache of the session. You can also remove the object and its collections from the first-level cache.

Monica - Er…

John - Additionally, you can control cache modes. You can use normal mode to read and write items to the second-level cache. Use get mode to read from the second level but you can’t write back. Use put, which is same as get but you can’t read from the second level. You can also use refresh mode, which is going to write to the second level, but not read from it and bypass the use minimal puts property, forcing a refresh of the second-level cache for all items read from the database.

Monica - I see. Ok. Let me think about this. Oh, it’s late, I need to go. Thanks for your time!

John - You’re welcome!

Giving Up On Hibernate

2 Weeks Ago

Monica - John, I thought we were entering a new era of software development. I thought we were doing a light-year’s jump. But, after four years, it seems like we are still dealing with all the same problems, only from a different angle. I had to learn Hibernate architecture, configuration, logging, naming strategies, tuplizers, entity name resolvers, enhanced identifier generators, identifier generator optimization, union-subclasses, XDoclet markup, bidirectional associations with indexed collections, ternary associations, idbag, mixing implicit polymorphism with other inheritance mappings, replicating object between two different datastores, detached objects and automatic versioning, connection release modes, stateless session interface, taxonomy of collection persistence, cache levels, lazy or eager fetching and many, many more. Even with everything I know, it seems like we’ve failed badly. It’s a software fiasco! Ultimate failure! Disaster! Armageddon!

John - Wait! What happened?

Monica - We’ve reached a dead end. Our application performance is ridiculously slow! To get a report, we have to wait two days! Two days to actually generate a dashboard for a customer. It means every day we have to increase our calculation tail, while our dashboard gets more and more outdated. Our DBA expert has been working two months to optimize some queries, while our database structure is a complete mess. There are developers supporting him, but the problem is the DBA is thinking in SQL, and the developers are spending days trying to translate this into detached criteria or HQL format. We are trying to use native SQL as much as possible since performance is crucial at the moment. Anyway, we can’t do much since the database schema just seems to be wrong. It felt right from the object-oriented perspective, but it seems ridiculous from the relational one. I’m asking myself: How has this happened? The developers are telling us changing the entities structure is going to be a massive effort, so we can’t afford that. I remember in the previous project it was a mess, but we never wound up at such a critical point. We were able to write an entirely different application to work with the data. Now, it’s risky to modify those generated tables since it’s really hard to make sure the entity model will always behave properly. And this isn’t even the worst part! To increase performance, we have to solve not only database issues, but also issues with the entire layer between our database and the application. It’s overwhelming! We have these new guys, you know, consultants. They are trying to extract data, put it into some other storage and then perform calculations from the outside. It’s all taking too much time!

John - I don’t know what to say.

Monica - You see John; I don’t want to blame you. I picked Hibernate to solve all these problems, but now I’ve learned it’s not a silver bullet. The damage has been done, and it’s irreversible. Actually, I would like to ask you something: I spent the last four years of my career dealing with Hibernate stuff. It seems I do not have a future at my current company. Can you help me?

So What’s The Lesson Learned?

Today

John - Hey, Peter, let me introduce Monica.

Peter - Hey, Monica! We’re building our new next big thing you know. It is going to be huge! We want to be like Uber! Do you know maybe how persistence…

Monica - Not Hibernate!

Wrap Up

Monica is a Hibernate expert. However, Hibernate in this instance was a wrong decision. The moment she discovered that her solution turned into a bigger problem than the original, it was the largest threat to the whole project.

Data is the central purpose of the application and, like it or not, affects the entire architecture. As we learned from the story, do not use Hibernate just because your Java application is using a database or because of social proof. Pick a solution that embraces flexibility. There are plenty of options for robust JDBC wrappers, such as JdbcTemplate or Fluent JDBC Wrapper. Alternatively, there are other powerful solutions, such as jOOQ.

About the author

Grzegorz Gajos, Poland
member since May 4, 2016
Grzegorz is a software architect with an international consulting and programming background. He's a co-founder and technical adviser for Open Tangerine software house. He also works as a software quality evangelist. Grzegorz is personable, communicates well, and has worked in teams of all sizes. [click to continue...]
Hiring? Meet the Top 10 Freelance Java Developers for Hire in December 2016

Comments

Samseen
I love the way you presented this. Very nice article!
giorgiofellipe
Awesome way to represent this perspective. Awesome article!
masilver
I've found this to be true with NHibernate in the .NET world, as well. It simply tries to do too much. There are fantastic solutions that are much more light weight, like Dapper.
Sergio Samayoa
This article will generate FUD on inexperienced developers. JPA and any other ORM (ex: Hibernate) are a very good tools for CRUD and OLTP. For OLAP (reports, import, export, etc) you must continue using JDBC or lightweight frameworks. Is very easy to realize that you will get into trouble with large result sets in JPA because it creates a List even without been an expert in JPA! I have been developing and deploying large high volume applications with JPA (Eclipselink & Hibernate using Tomcat, Weblogic, Wildfly, Websphere, etc) without a problem. Of course all those operations which will be over large datasets are done with plain JDBC or lightweight JDBC frameworks and / or with stored procedures inside the database.
Tobi Olanrewaju
This is so true. I use hibernate though but I always pay attention to the generated sql. Once i'm not satisfied with it, I use native queries.
Alejandro Pablo Tkachuk
This is hilarious. And very true. Hibernate is just an example, there are many many technologies going around there being used just because of social proof or fake silver bullet status. Nowadays there are also a new kind of convoluted-idiotic-scriptive-lazy-hibernates-alike technologies that are making the world a worst place. I would just call them "the hipster technologies" and I don't even want to start writing about them, but If you find this article funny I know you know what I mean. Great article Grzegorz.
Julian Andres Guarin
Well, in the Wrap up you wrote: "at this instance Hibernate was a wrong decision", when or in what instance do you recommend to use Hibernate?
Harsha Hegde
Great article! Very true! SQL isn't evil! Nor is Hibernate. Like any technology tool, using it wisely is the key to success.
TerraT
Great breakdown of the progressive impact of making technology choices based only on "fanboy status". This could be applied to many things but ORMs in particular are the scourge of enterprise scale systems. Data is nearly always the limiting factor for performance and stability and embarking on a quest to produce "the next big thing" by treating your data persistence as a second class citizen is a certain short cut to failure. ORMS are great for prototypes and for tactical apps with short life times. For everything else, cut corners elsewhere if you have to but not on data persistence, I guarantee you will regret it and it is the hardest mess to extract yourself from once you have let it go too far. Btw lets not hold Hibernate up as a rogue wolf, this exact same thing applies to Entity Framework, CSLA, NHibernate and probably every ORM out there, it is fundamentally an anti-pattern, and you can only afford that on throw away apps.
Giorgi
Using Hibernate for forgetting the Database is WRONG! Using Hibernate to make it easier to just communicate with Database is CORRECT!
Renato Dinhani Conceição
Most problems with Hibernate happens when people try to use their objects in business rules and even in the GUI side of the application (these were my mistakes). A simple separation between business/domain classes and persistence classes allow me to mix Hibernate, Sping JDBC helpers and JDBC itself in a single project without any issues.
TerraT
But even Dapper is only a partial solution... still it is a good partial solution, and they at least didn't fall into the trap of immediately embarking on a quest for some mythical animal of persistence :-)
Electrotype
Thank you for taking the time to write this!
Cristian
really fun to read. Ty.
NeeL
That's exactly why we created our "ORM-like" which just helps with easy SQL but goes nowhere beyond that
TerraT
I agree if you must use an ORM then this is the best way forward, but where is the productivity gain? You now have an ORM to prevent the need to write database mappings, but are writing a load of mappings to map them to domain objects. You quickly end up in the situation where you have one person hold the light bulb and a 100 others lifting and turning the house... Edit: also not to mention the caching mechanisms that are pointlessly churning away for scenarios that don't exist anymore. In disconnected state scenarios a lot of ORMs are a performance drain.
Langley
What I understood from your article is that Monica chose a tool without knowing what it was/how it worked, and it took her 4 years to learn it. I think that will fail no matter what Framework you use. I see this happen way too often, companies ditch SVN and start using Git because its the next big thing but they don't want to do feature branches because its easier not to, so they keep using it same way as if it were SVN which only leads to developers frustration as they have to learn new stuff that is giving them 0 advantages so they see it as a counter productive tool. They never really took the time to really learn the tool, how it worked, its strenghts, its weaknesses, etc...
Michael Teter
I had to laugh at the premise though - if you're building the next Google or Facebook, you're not using Java.
Christine Slotty
I use Hibernate for plain CRUD, but not much beyond that! It's good for mapping views to read-only objects, too. But for more complex stuff (actual processing) I write a lot of DB procedures because processing then happens right where the data is. The EJB layer doesn't do heavy processing at all. Some, but not much.
Christine Slotty
You do want to use Hibernate because it spares you from writing thousands of boring SQL statements. But beware of the limits of what Hibernate can do for you!
TerraT
That's a great reason to choose something, because doing it properly is boring. Like a mechanic trying to fix your car with a machine gun because using spanners is boring. The sad truth is that you are probably not alone on a massive scale and that is why IT is such a disaster zone. Too many i'll only do it if it is fun developers seem to have forgotten that they have a job to do and that some times tedium is necessary.
Luc Préfontaine
I dumped Hibernate years ago. It's especially bad if you try to attach an app to an existing database with a flaky design. The Hibernate tools generate wrong bindings and by the time you find this, you will be fixing the generated bindings... by hand. I turned my back on frameworks, Spring being the worst. It grew like a cancer to something bloated. As soon as you need to tweak things or you end up outside the ditch of the 'framework' you will die. And if your app is to be long lived, you never known what wrench will be thrown at it over the years.
Luc Préfontaine
Then just use jdbc directly with pooling and customized caching. As efficient, no impedance mismatch. No extra brain power to understand WTF is hapenning behind the scene. No extra layers of translation, just spit out business related objects.
Rohi
really nice article. Honestly I don't like Hibernate, for my new project I was examining a combination of Spring Data over JPA for simple CRUD, and jooq for all the rest. But reading your article, I think it's maybe better to deal only with jooq....
Michael Teter
If you know Java, Python, and PHP you should have your answer already. Both Python and PHP (which I am not saying are similar) are "quick" and relatively low overhead in terms of lines of code and programmer effort. Java is super wordy and comparatively fat. Of course it's much faster and its JVM is lovely, but it's not something that fast-iterating companies use to hit the ground quickly and get a product out the door. There may be some places in the world where people are trained as if Java is the ultimate (and I'm making no judgement to that), but frankly it's rarely the first choice of modern startups. Thus, anyone hoping with any chance to be the next Google or Facebook would not use Java. They would probably use Python, maybe Ruby, possibly Clojure, more likely Scala, or Go. I probably left out a worthy language, but Java would frankly be back slightly ahead of C++, but behind even C#.
Dragan Bozanovic
Monica has been using a bike to transfer goods from point A to point B for years. However, the company she works for noticed that its competition was taking over the business. They decided that they had to change something and put Monica in charge to design new transportation architecture. Monica - John, how are you transporting goods from point A to point B? John - We're using trucks, we found them to be much more efficient than bikes. Monica - Thanks John! John - You’re welcome! Monica found a 5 min tutorial about truck driving, put her bike aside, loaded the goods into the truck, turned on the key and put the truck into motion. 2 years after Monica has just returned from the hospital. Thank god she has completely recovered from injuries. Monica's manager - We have to improve the way we ... Monica - Not trucks!
Derek
What I understood about the article, Monica was not aware about how Hibernate works internally since the beginning. If you use EAGER relationships, some JOIN tables strategies, CASCADEs and "fetch join" not knowing what is happenning in the generated SQLs, you will probably have performance problems with Hibernate. Monica also had several signs that the application needed some performance intervention before all turn chaos. Probably the team continued to make the same mistakes with Hibernate. Probably there was time to resolve the errors that existed and avoid new mistakes. I've worked on an application that nothing worked because of the misuse of Hibernate. After a few weeks, the application was still with several problems, but working as intended. About the unsolved problems the team already knew what needed to be improved to have a better performance and without discarding Hibernate. Hibernate is a very permissive framework. Avoiding some pitfalls of it, as I mentioned earlier, you will have exactly the SQL statements you would like to have using JPQL / HQL or Criteria. Of course, sometimes you need to write native SQL statements but they are rare and used to solve very specific problems. Not use Hibernate (or any other ORM) may cause the team to create your own ORM. But are big chances of this custom ORM become more complex to use, maintain and much more bugs. The article was well written and engaging. But without knowing exactly what problems they had, as the tables were mapped, examples of problematic queries, etc., we will not know if Monica and her team did not use Hibernate in the most correct way or the problem was with Hibernate.
sgtpepper11
Conclusion: Mónica was promoted to arquitect but she chose an orm for which she had no shity idea of how to use it and it's pros and cons, and she also didn't have any developer in the team that knew about it. I think Mónica has to search for a new job.. she's pretty dumb.
Aishwarya Sharma
The original Google search was made with Python. Facebook was made in PHP iirc. Why would Java be inherently worse than the other 2 languages?
Grzegorz Gajos
Sergio, thanks for the comment. I completely agree that Hibernate works but it doesn't mean it is the optimal solution. You can create simple CRUD-s with other tools as well http://www.jooq.org/doc/3.8/manual/sql-execution/crud-with-updatablerecords/simple-crud/. This is just not any major advantage.
Grzegorz Gajos
"I see this happen way too often". That was exactly the reason why I decided to write this article. The problem is that consequences of those decisions are not affecting authors because they are working somewhere else already. It's sad when great project become a "legacy" quickly.
Paul Rivers
"we will not know if Monica and her team did not use Hibernate in the most correct way or the problem was with Hibernate." It doesn't matter. Hibernate was used because it promised to avoid those extra complications and that extra work. Instead, it made more issues than it solved. If you have to use the framework "in the most correct way" to see benefits, you're better off doing it the native way and saving yourself the hassle of also learning the framework.
Grzegorz Gajos
Thanks Luc. Exactly! I cannot understand why so many people prefer to use complex multi-layer solutions in hope of future advantage which is not clear.
Taran saini
very well articulated..cheers man!
Grzegorz Gajos
Thank you! I think that way of thinking you mention is what makes Hibernate so popular. It encourage to pick Hibernate and just use it right. When you have any problem with Hibernate, you think that you're just not using it right. The real problem is that Hibernate just adds additional complexity which is not necessary.
Grzegorz Gajos
Look at the http://hibernate.org/orm/. It feels like perfect match for any true, large, enterprise application. Maybe she was just fooled by the market or the people?
Grzegorz Gajos
Derek, thank you for sharing this. I was creating this article from my and other people experiences similar to yours. I found also people who actually create their own ORM for the project. For very long time they were struggling if that is the right approach but they never have any problems. They created ORM that fits exactly their business model. It lack lots of features but they implement what is most important for them. Fun part is that they have also one project which is using Hibernate but absolutely everybody prefer their internal ORM.
Grzegorz Gajos
Thanks NeeL. I can imagine that it felt noobish. I see that many people look at solutions like this: "typical junior mistake" but I see in many cases is just work better.
Grzegorz Gajos
@renatodinhani:disqus, I would like to ask similar question. How mixing Hibernate with other solutions is helping with your project?
Grzegorz Gajos
"convoluted-idiotic-scriptive-lazy-hibernates-alike" love it :D. You just created "CISLHA" term.
Grzegorz Gajos
You still need to know SQL, you still need to write SQL (native queries), you still need to write HQL, criteria, etc. I prefer to see "boring" code, rather than "CISLHA" code which I spent hours to debug.
Paul Rivers
Why would someone who isn't already with it use it then? You can write any Java program using a text editor and the command line compiler. But, if you've used both (I have) using a decent IDE is way way better. There are no drawbacks. You can write a web app using servlets and jsps. I have. But using a web framework is much much better - faster, less buggy, a lot easier to track down what's happening where. There are no drawbacks. You can talk to the database using SQL. I have. But using Hibernate is...often worse, only sometimes better. Sometimes it saves time compared to writing SQL, other times it's far worse. It makes simple tasks easier and complicated tasks worse. The one thing you know with Hibernate is that you'll have to invest more time in learning both Hibernate and SQL, rather than just learning SQL, and that it adds an entire layer of complexity that gets in your way of solving difficult problems. The reason to use a framework is if it makes your job easier - faster, less buggy, less stress, etc. Hibernate does not do that.
Grzegorz Gajos
Thanks. I know it can be applied to many technologies. I'm just very familiar with Hibernate so I could point out some "problems". While problem is generic I believe community have to fight each of this "google first result" projects one by one.
Paul Rivers
Is it dumb to do that? Yeah it kinda is. Have my last 3 managers all been this "dumb"? Yes they have. "Monica" has been the norm the last year or two - the only difference with Monica is that the real world manager who forced the decision on their team usually tries to blame the team for it rather than admitting that it was their fault.
Rohi
I know tons of startups using Java as their first backend programming language.
Luc Préfontaine
Job security ? Bureaucraric approach applied to software development ? The worst problem in IT these days comes from wetware, hardware has been doing fine in the last 25 years, software more or less. Where is the largest number of interactions with wetware ? In software. Add to this the democratization of computers and the lack of historical perspective and culture of most IT people. I dealt with my first OO language in... 1980. And it was far better than the first five incarnations of Java if not all of them... 😬🔫 Like one author of a comic strip said in the 1970s, when a rich person takes drugs, it's classy, when poor people take drugs, it's misery. When a rich person travels abroad, it's exotic, when ordinary people travel, they're parked on the beach like a herd in a stable. 😂 Replaced rich by educated in the sense of a broad vision of this world. There's your answer. 😩
NeeL
Not at all about the noobish feel ! It just points exactly what to take into account when choosing a stack before starting a project, and this is so true ! When I was talking about our "ORM-like", I meant that we knew hibernate went too far with data so we just decided to create a "mapper" which just maps resultsets to entities but we trust the developer with the SQL magic ! Great article !
Belahcene Benzara Tahar
Getting rid totaly from SQL was totally wrong from the start, using a hybrid solution between a hardly coded SQL layer and the ORM layer should be the wise decision, SQL to handle complex situations, Hibernate to deal with the boring basic CRUD queries.
Grzegorz Gajos
To be honest I cannot imagine a situation when Hibernate would be a better choice than jOOQ. In some cases, it's enough to use just JdbcTemplate or even plain JDBC. I do not recommend because I've never seen a project where using Hibernate was fully justified.
Grzegorz Gajos
This is one of the cases that undermine the entire Hibernate approach. You have to keep an eye on the queries if you want to have an optimal approach. It requires great knowledge not only about the SQL but also about the Hibernate schema to write native query properly.
Schaka
If your application is built in a way that having an object graph is useful and you are working on a CRUD app with many developers so you require maintainable code, plain SQL is just shit. Especially if your queries are so simple that you don't have to worry about Hibernate creating slow queries. For reporting and large, complicated queries, there is always jOOQ.
Grzegorz Gajos
That is exactly the problem of Hibernate. It is trying to provide an ultimate way of OO database approach. There is a reason why we have smaller specialised libraries rather than UltimateFramework that handles all cases for us. Doing too much is a pitfall wrong design. I admire the work that has been done by Hibernate developers but it afraid me when I see it was copied over to the other languages with all the problems as well.
Grzegorz Gajos
This is not advertisement. jOOQ is really great: )
Luc Préfontaine
Many architects never stay long enough in a business to live with the (painful) consequences of their (bad) decisions. No retroaction loop about their choices = no feedback = no corrective actions = more bad decisions on the way. Many architects are influenced by the marketing hype surrounding a tool and just follow the herd. It's not their fault, it's that job slicing machinery in IT designed by HR. The job environment is toxic. You cannot gain experience in a broad sense. Only very narrow experience that may not relate at all in delivering a resilient solution. To gain experience, you need to walk in the quick sand from time to time to see if you still have a foothold. Here Monica is now a better architect than many, she's been burned once. She might be cautious before making a critical design choice. However given the length of time it took to get that burn, it will be a very slow process for her to gain more experience. I saw a few big projects never making it to production because of stupid decisions induced by hype around untried tools and methods. Go figure...
Grzegorz Gajos
You are using "social proof". This is the main reason why we have so many projects using Hibernate. It would be great to read studies or some science documents about this topic but there is none. If "they" are using other technologies it doesn't mean that it's right and optimal.
Luc Préfontaine
You are absolutely right. Hype about tools like Hibernate kills the industry. Once you get on board this ship being promised a memorable cruise well, you might as well end up with a turista eruption instead 😂
kigster
Great write up! I've used Hibernate on several java projects before switching to ruby/rails. I find that active record is a much better OO framework: it fits just right between being too abstract (Hibernate) and too verbose (plain SQL), with just as much (if not more) control over the resulting behavior. As much as Hubernate saved initial time during the java project, nearly every problem that happened to Monica happened to me at some point. And for those thinking "ruby doesn't scale" or "rails doesn't scale", you should seriously reconsider your association with the job of a programmer or an architect.
kigster
Completely agree with you.
Luc Préfontaine
I remember seeing a demo at a conference two years ago. The statement was that you could build a web app in java in 45 mns. Sure, with some Groovy, half a dozen external tools and a dozen editor macros to expand ceremonial code specific to the demo. Ridiculous. It only demonstrated that Java was a poor choice to implement server web page rendering with minimal effort and a decent timeline given the simple page that resulted from that 45 mns session.
Luc Préfontaine
I use Clojure/ClojureScript/Reagent and Re-frame. Now it's efficient to write a web app. Same language backend/frontend and common code sharing between the two... After years of enduring Rails... gulp...
Steve
Great and hilarious article! The best I've read on Toptal!
Christine Slotty
Of course you still need to do all that! Don't talk about my code, you haven't seen any of it. Of course you have to know and write plenty of SQL still, but you can concentrate on the stuff that matters - forgetting about the simple CRUD operations. This is about entropy! Keeping yourself busy with something that can easily be done by a library (that you have to learn to use properly, too, of course) is highly inefficient and not what we're paid for.
Christine Slotty
Please don't judge if you don't know me! I think I do use Hibernate in a very sensible way. The "boring" SQL statements are plain select/insert/delete/update operations that can be easily monitored by enabling a couple of options in the Hibernate config. Besides, I do write a lot of sophisticated SQL procedures and queries, in places where they are needed. In cases where it makes sense, we even deliver JSON directly, the server layer doing no more than providing the REST route. I have seen files containing thousands of "boring" SQL statements, it's nothing better than confusing and error-prone. That's what Hibernate can do for us - hide away the "simple" stuff! Of course you have to know SQL well, and you have to learn to use Hibernate properly. And then use both worlds appropriately.
Christine Slotty
By using simple Hibernate POJOs, you spare yourself from writing the same SQLs over and over again! You can use the data (once loaded) as you do it with everything else. I have done all of it - not using an ORM, using Hibernate as a noob and using it properly (now). And I do see value in it - as long as you know its limits. Hibernate is no more than a simple abstraction layer in order to not spend unneeded effort.
Grzegorz Gajos
Keep in mind that jOOQ have also very friendly CRUD http://www.jooq.org/doc/3.8/manual/sql-execution/crud-with-updatablerecords/simple-crud/
Grzegorz Gajos
I didn't want to offend you or your code. I mean that simple CRUD is not what Hibernate creators have in mind. At least it is not any major argument that justify picking Hibernate. You can create simple CRUD-s in JdbcTemplate using bean mappers (see BeanListHandler for example). You can use it in jOOQ http://www.jooq.org/doc/3.8/manual/sql-execution/crud-with-updatablerecords/simple-crud/.
Christine Slotty
Ok, no problem! They might not have had it in mind, but that's what I've turned out to be using it mainly for! Since Hibernate is well known and JPA is part of a standard, chances are high that Hibernate is chosen in a project. It's simply a framework I've been using for a while, and the JEE standard is something that customers like in terms of "reliability" or credibility of a development provider. I believe you that there are other (better) frameworks for doing that - thanks for the link! Customers, projects, the market - it's not just focusing on the best available methods or frameworks. It's an evolution of things and methods and we're still somewhere in the beginning, far away from doing things in an optimal, efficient and well-known way. I don't see a problem though, using a framework or library if, in the end, the software performs as expected (which it does in my case - because that's a constant quality measurement we apply to everything). This discussion and its results should at some point make their way into education! Because that's where things start and get established. And you know what? There are still so many other deficits, like f.ex. developers still not writing unit tests, or development tools that many projects still struggle with and so on.... we're on a rough ride still, in software development.
Michael Teter
I never said Java was not successful or that Java was not useful. I just said that if you're doing a startup (that might become successful and large like the two companies mentioned), you probably won't start with Java. *As for your comments, Google bought Android in 2005. Google did not choose Java for Android (although I'm not saying they would _not_ have if they were starting). *Twitter began as Ruby (on Rails), and then moved to Scala. They did also later build some back-end (search-related) systems on Java. The point is, when starting up, you typically want agility and fast iteration cycles. Java finds a nice home in big back-end systems, but it's not what you choose for hitting the ground fast.
Christine Slotty
Sorry for "spamming" - one more thing to add: There are a lot more factors to libraries than just their effective quality in programming! In the past years, we have seen a lot of new libraries and methods pop up, which have revolutionized the market to a great extent. It's a way of creativity bursting into the market, everybody being excited about it. All those high level scriping languages, all the Android development, JQuery, node, whatever you can think of which has been innovative and moving people. I don't know if this "step" has come to slow down or stop yet - of course there has to be a time for review and consolidation. Maybe that's where we are right now and why we're discussing it!? What I want to say: In order for a library to be successful and "trusted", it needs a couple of factors. Good support and maintenance, publicity, a broad user base, probably even acknowledgement of those big companies like Google, Amazon, you name it. Acceptance as a "standard". JPA has been based on Hibernate and even if JEE is a big beast and probably not optimal, it has indeed been improved over the years, and it simply has a very heavy weight in customer projects! At least I have spent the last 13 years in not much else than JEE. I love Perl, too! There is so much great thought and sophistication in there. But nobody wants it! By saying "nobody" I'm talking about corporate customer projects, which are the only ones willing and capable to spend a lot of money on custom software - which is what feeds me, at least. I love open source software, I use practically nothing else. And I admire anyone striving for quality software and putting time into open source development. I personally just don't have the time for it, though, so all I can do is try to find my ways through this jungle and stay safe and requested for projects!
Grzegorz Gajos
Thanks for sharing your thoughts. I am always seeking knowledge of people with many years of experience. There is always some knowledge which is never outdated. Yes, there are a lot more factors to libraries than just their effective quality in programming, but it is something that scares me the most. The name of the company behind the product is far more important than the product itself. I wish there will be time for review and consolidation be it seems it won't be. Every "small" decision at the beginning of the project is creating jobs and programming markets for years.
Grzegorz Gajos
I think that main problem is not with the Java itself but lack of robust web framework that can truly compete with Rails like solutions. Play framework is close but community around is just too small (why?). I think that this has to and will change. The evolution of Java is slower that other languages but very consistent which is always win on the long run.
Michael Teter
I think another big point is the type of developer that uses the languages. Not speaking badly of Java people (because I myself introduced Java to my client in year 1999), but less conventional, out-of-the-box-thinking developers tend to look for tools that give them special advantages in highly competitive situations. Before I did Rails, I did JSP and Servlets. I was happy enough with the Java tooling, and I built my own frameworks. But Rails came along and made it so easy to hit the ground running that it took over. And like many Rails developers, I came to learn when it was time to move from Rails to other tools and frameworks (just as Twitter did). The same applies to any framework or toolkit or layer (like Hibernate).
Christine Slotty
It's true! It's often no more than plain chance, as to what ways (tools, libraries) are chosen in a project or "in the world". That's how nature works and we're still nature, even if we try everything to deny it! ;-) That's why I'm talking about evolution. Discussions like these are good and a necessary part of it. But think of cars - how long did it take to get where we are today, how many people have died, and still, can you say which car is the best choice? No, you can't, it's based on preferences and context. Have you ever been in a discussion about which hand saw to use for woodworking? Where people would nearly kill each other at some point? And that's only wood working, it's only for cutting wood into pieces.... And we're talking about software here, with an unlimited degree of complexity and diversity. Anyways - that's the game and it's always about making good use of tools! And yes, you can use a hammer to open a beer, too. :-) Back to being serious: Sometimes it's all about making a safe choice, and Hibernate is still pretty safe - until something else gets hyped and identified as evolving to be a new "de-facto standard". Until then, I won't take part too much in these discussions, I guess. I'm not a tool-builder - I use tools. And for me all hammers are good as long as I can get a nail into the wall with them.
Derek
If John promised a "silver bullet" for Monica without alerting to avoid some things in Hibernate, the problem is John's promise and not Hibernate. Escaping some pitfalls of Hibernate you can use it to avoid various complications and extra work. Any tool needs to be used correctly to do the right work. Any developer can shows bad examples of use of any framework. Even a knife can be useful for good things but can hurt people too. Hibernate is a permissive framework, acts at a crucial point in the system and allows bad decisions. You need to pay attention on that, even using your own custom ORM.
Vadim
Thanks. Very nice article. ORM (Hibernate, ..) does good job, but you should understand its limitation. Good Martin Fowler's article about this topic: http://martinfowler.com/bliki/OrmHate.html
Renato Dinhani Conceição
The simplicity of writing natives queries comes first and it is usually enough because is most cases only one or two tables are involved in the queries, so it is easy to parse the results to domain objects. Spring helpers like SimpleJdbcTemplate, NamedJdbcTemplate are used in these cases. But sometimes when the graph of objects is too complex, it is easier to use Hibernate than writing natives queries to store and retrieve, So in this case we use it without any problems. This works because the data access layer receives domain objects as parameters and return domain objects as results (domain objects are not Hibernate POJOs). If it will use native SQL, Hibernate, or even a web service call it is just a matter of implementation of the DAO objects. Mixing both helps because each developer has the option to use what they think it is better for each use case.
Vlad Mihalcea
You can always blame the tool for not using it properly, but remember that Hibernate has a market share of 70% in Java world: https://vladmihalcea.com/2016/08/18/jpa-providers-market-share-in-2016/ If Hibernate was to blame, why do you think there are so many successful projects using it? That being said, instead of blaming the tool, maybe it;s time to check these 80 articles that I wrote on my blog: https://vladmihalcea.com/tutorials/hibernate/ or my book: https://leanpub.com/high-performance-java-persistence
Michael Romose
Google uses Java for all the big stuff. Why on earth would you laugh? Twitter also converted to Java/Scala. (https://www.quora.com/Why-did-Twitter-switch-to-a-Java-based-front-end-after-successfully-using-Ruby-on-Rails-with-200-million-users) Android is based on Java. Java is a hell of a lot more fast and succesful than you realise.
Grzegorz Gajos
I agree with you that complex save operations (complex graphs) might be easier (less lines of code) in Hibernate. However, don't you think this might indicate bad design of the schema? Why would you want to create such complex graph relations in the first place? I know what you mean but I think that HDD (Hibernate Driven Development) is forcing you to create such beasts. Moreover, in SQL you can create views to simplify access to some part of the relational model (I know it has many limitations).
Destan Sarpkaya
if this is your answer to this comment/critique then you need to change the "Wrap Up" part along with the title!
Destan Sarpkaya
The real "Wrap Up" in this article is RTFM before using something.
Grzegorz Gajos
Thank you for the links. I really admire you level of expertise in this field. I especially like this interview with you https://www.javacodegeeks.com/2015/04/jooq-tuesdays-vlad-mihalcea-gives-deep-insight-into-sql-and-hibernate.html :)
Grzegorz Gajos
If only people who are selecting Hibernate were aware of the limitations ...
Grzegorz Gajos
The thing is that it was never meant to be just CRUD. It was designed as very sophisticated tool and ultimate ORM solution. However, I completely agree that such true and simple "JavaCRUD" library is probably not existing ("yet") and Hibernate could be one, but it's not.
Grzegorz Gajos
Wrap Up: "Before starting new project, please take 4 years to RTFM :)"
Vlad Mihalcea
You might be interested in this "High-Performance Hibernate" presentation from JavaZone 2016 too: https://www.youtube.com/watch?v=BTdTEe9QL5k&t=1s You are going to see Hibernate in a different light, I bet!
platapapin
I've been around long enough to remember when people were making the same argument about using operating systems versus writing for the bare metal. Just saying.
Grzegorz Gajos
The thing is that SQL is not assembler. Imagine wrapping around high level language (SQL) within another high level language (Java) using something that is not OO (annotations, xml) to produce ORM. Plus, I don't blame ORM, I'm pretty sure it can be done right, just not this way.
B'bek Shakya
Good article sir.
Sergio Samayoa
It depends on what "optimal" means for you. Persisting a complex graph with a single method invocation is for me optimal. - BTW "simple CRUD-s" is wasn't I mean. Someone else tracking the properties changed in the entity then persist those changes at transaction end is optimal for me (Eclipselink is superior over Hibernate on this). Getting eager FK's data (ManyToOne default) is optimal for me. Less time to market is optimal for me (Note that eager loading child records -OneToMany- IS NOT optimal). Writing less code improves readability (code is more often read than write) - you can focus on what not how. Problems because the session gone away ? beginners error when they don't even understand the web applications - use extended context or detached entities. Nowadays loosing some computer cycles (ex: eager on FKs, generating SQL from JPQL / HQL) is not a major concern. I have heard a lot of complains on ORM in general and Hibernate in particular and my conclusion is that most developers failed because they didn't spend the needed time understanding the technology making it worst when they use it for a high profile project as their first project; when they fail they blame the ORM framework not themselves. Do you use a screwdriver to drive a nail or a hammer? ORM is a good thin but NOT a replacement of JDBC or lighter frameworks. You need to use the correct tool according to the task.
Sergio Samayoa
Correct! Wasn't Hibernate which almost ruined her career, was HERSELF!
Sergio Samayoa
hahahaha! Exactly!
Sergio Samayoa
> ...Why would you want to create such complex graph... Business needs.
Sergio Samayoa
Wow! So basically you write your Web apps with servlets? Or write your own net layers? Or threw away Java and write using C? Did you threw away also RDBMS & SQL because navigational ISAM/VSAM access is "quicker"? Again: Frameworks are simply tools that you must learn and use according to their intention and its capabilities and restrictions else you will miserably fail.
Langley
So what you are saying is Frameworks are meant to be used without learning them cause learning them is a hassle? There's no "most correct way", there's many different scenarios and many different solutions, your job as an architect is to learn how to differentiate them.
franzsee
I think I understand what the author is trying to say, but it just came out to me that an 'architect' used a tool and took 4 years to figure out how to use it (and what it's not for). Secondly, i am still not convince that Hibernate was not the correct choice. Sure, the cons were mentioned, but the pros were not. But then again, the story would still be the same if you pick a different technology - there would be pros and there would be cons. Like the author said, there's no silver bullet.
Grzegorz Gajos
Sergio, thank you for the comment. Really like it. First, I'm not against ORM, jOOQ is the ORM as well (not sure about jOOQ author opinion here). I'm against Hibernate because it violates "Principle of least astonishment" hard. Because tracking properties means it is going to persist your data without invoking save (in some cases). Because annotation mappings and fetching modes are hiding trivial database operations (selects) in non-trivial approaches. Because you need to know what is Hibernate session and how exactly is working. Because you need to spread annotations and XML across the project. Because you need to know about extended context, detached entities (this is something I was too afraid to use :)). The point is, that you can be an expert in database domain and you will be good no matter what you are using to speak to that DB. If you are using ORM, you need to be expert in DB and the ORM as well. The problem is that Hibernate domain seems to be more complex than the database itself. I was dealing with few spaghetti old Java projects and few overengineered with ORM-ish projects. It was significantly easier and faster to reverse engineer (learn) spaghetti rather than overly complex ORM-ish like solutions. In projects where developers are smart, you can do whatever you like. It is going to work anyway. On the other hand, maybe that is the root of evil - too smart devs?
Grzegorz Gajos
Business needs features, dev team is responsible for the abstraction (implementation).
Luc Préfontaine
Clojure/Clojurescript, HttpKit, relational dbs yes butwe stay away of heavy normalization, stored procs with business logic and so on. It's easier to deal with these things inside your app. And all of that in 10 to 15 times less code than Java with all the usual gizmos. We created a product in 2008 with all the hypped gizmos at the time; Spring, Hibernate, blabla... this thing became bloated in a matter of months. It's even worse when you do not control the db design or third party APIs. We soon realize that we would just fail trying to get this running in multiple sites imteracting with multiple foreign databases. The amount of time and effort required was tremendous and the tooling was not strong enough to really isolate us from third party design mistakes. We had issues with Hibernate, if the database we were interfacing with had a poor design, Hibernate does not care. But by the time you start using it, you find out that you need to tweak all these generated bindings by hand to make it work. Not practical. We are much more apt to react to changes now and deliver faster. We created tools to define business views that return readily usable business entities using descriptive data. That lessens a lot the impendance mismatch between our code and whatever database design we have to deal with. And it makes changes trivial to implement. Pulling an entity with all it's related attributes is 5 lines of code total, no generated bindings, .... The generated views are made of calls to generic stored functions. One version per db brand. Since we do many integration projects, it's been a breeze to deliver in a short time. Hibernate 0 our stuff 100.... so far. Your remarks seem to imply that we are primitive people. On the contrary, we faced real challenges far beyond the average integration project. There's been a lot of thinking done. There's a new world outside of Java and the framework ditches... you should have a look at it. My 2 cents.
Polaco
What i can get from your article is that Monica never ever read the hibernate documentation nor have the less clue how hibernate works by any chance, a complete ignorant that in 4 years never learnt a thing about a framework she is using in daily basis and she is blaming the framework by her incompetence. Though the autor seems to knows at least it seems however he tends to blame hibernate of issues that are completely out of it's scope. Hibernate is not a magical nor responsible to generate migrations for production and even less responsible to know when another application has performed a change to the database over a table that your application is also using, that is your flaw as an architect maybe. Hibernate allows you to perform many optimizations in lots of ways and if she is taking two days to generate a report maybe she also knows nothing about paralelism nor how to perform bulk operations with hibernate, also maybe she has database issues like slow query performance (I wonder if she knows or would ever think about looking at the explain plan of the queries), and many other things that can arise in the middle, and again if she has read the doc she would have seen that for bulk operations you need to clear the session, perform commits by batch or whatever strategy she may have choosen. So... in the end a lazy person is blaming the framework by it's own design errors and she is not even thinking on investigating nor learning. Hibernate has it's pros and cons as any other thing in life, learn, use it wisely, read about it, tune it, so on. Good luck.
Polaco
totally agree!
Sergio Samayoa
> ... because you need to spread annotations and XML across the project Apart from persistence.xml I only use annotations - Very rare cases I override something on orm.xml > ...Because you need to know what is Hibernate session and how exactly is working That's the main point: Tools need to be used correctly. > ...that you can be an expert in database domain and you will be good no matter what you are using to speak to that DB. Correct. But blaming Hibernate because devs don't take the time to learn what are and how to use those it is not fair. > If you are using ORM, you need to be expert in DB and the ORM as well. mmmm.... Before I used ORM (was "pure" Hibernate more than 10 years ago) I already had RDBMS experience so when I saw that queries returns a List first thing I realize that is crazy to use it for large result sets; When I say eager/lazy fetching I easily presume that former use JOIN and latter may use DISTINCT + JOIN or secondary query (I confirmed both, at that time, looking at the Hibernate's log) so I immediate knew that I have to be very careful using that feature; Since early versions of Hibernate you can get the schema objects created but I already know that I have to create indexes other than PK and FK that I may need. Bottom line: AT that time I had experience on RDBMS but none in ORM but, without been an expert on ORM, my team and I crafted a good application using Hibernate because we know that Hibernate is not magic, just a better way to persist objects in RDBMS. I don't think you need to be an expert, just need to be "careful" or "inquisitive" or "curious" or "methodic" - Get little deeper before blindly commit to something that sounds "cool" or "new". > The problem is that Hibernate domain seems to be more complex than the database itself Perhaps but may be because you are using a relational database to store objects. > ... too smart devs? hahahaha! At contrary, too much "non smart" developers. A smart developer is the one which LEARNS frameworks, techniques and so to do his/her job EASIER because there are coolest things better than been in the front of the screen. Those "spaguetti" code you mention is not from "smart devs". Regards!
Christian
Obligatory talk: https://vimeo.com/181766947 The Silver Bullet Syndrome by Hadi Hariri
Derek
I already see exactly this problem occur in a company. They try to use GIT instead of SVN. After few weeks, they came back to SVN, saying that the GIT was very bad, complicated, etc. After some months, they try again, because the new hired developers talked about the good experience using GIT in their last jobs. Today every one are very happy and productive with GIT, even the people who did not like the GIT on the first try. No one thinks of using SVN again.
Paul Rivers
Using slq, and hibernate, and JOOQ is "just shit". I didn't find using sql to be that big of a deal - if you enforce that it's organized decently. Keep static queries in text files, keep dynamically generated queries in the service layers. Objects graphs weren't a huge deal either because CRUD apps tend to be relatively simple in how many objects they want saved in one request. It's a pretty small number. We kept running into issue after issue with hibernate. Last one I remember was that a legacy table had a composite key and they didn't want the table changed. 3 developers could not get hibernate to play nice with a composite key. 1 dev got hibernate to do a composite key on a different table, but it would not work with the one we needed it for. You just don't have these bizarre issues with regular sql.
Paul Rivers
SQL is "boring". Hibernate is "exciting" when stuff relatively randomly doesn't work. Maybe you have a legacy table with a composite key - oh shit hibernate can't handle it! (run into this one myself hibernate claims it can work with it but we couldn't get it to work). Hibernate is exciting when you thought a column was a unique primary key and instead of just screwing up that request, Hibernate screws up all the requests after that because of how it's cache works (again something I ran into). Hibernate is exciting when at the last second it turns out that the legacy app you're converting allowed wildcards, which work fine for dates and numbers in sql (with a little extra syntax) but Hibernates Criteria API can't handle it and you have to rewrite the whole thing. Working with Hibernate made me appreciate working with "boring" sql where things are fairly predictable and if it can't be done with sql, it can't be done with the db at all - you don't have to make excuses for how the legacy app could do it fine but your hibernate framework can't handle it.
Lukas Eder
Interesting story :) Here's a quick rule of thumb that works many many times: - You have the object graph persistence problem? Use an ORM. - You want to read / write data in bulk? Use SQL. - You have both problems? Use both.
Lukas Eder
jOOQ author here. <blockquote>jOOQ is the ORM as well</blockquote> Of course. Strictly speaking, jOOQ maps relational tuples to object oriented tuples (<code>org.jooq.Record</code> or your own class, which is also a tuple as Gavin King always said). jOOQ doesn't (yet?) support mapping denormalised tuples back to nested collections, which is what OO folks love so much, because it focuses more on the strict SQL mindset that can mostly do without nested collections, but in the end, there's no strict, conceptual difference between the object model and the relational model. I've blogged about this here: https://blog.jooq.org/2015/08/26/there-is-no-such-thing-as-object-relational-impedance-mismatch/ TL;DR: Yes, you can call jOOQ an ORM, although, that is not its primary feature and jOOQ doesn't go "all-in" with what modern ORMs claim to be able to do.
Christine Slotty
Well..... sure, just don't use Hibernate if you don't want to or have to! I'm not at all opposed to not using it. I'm just saying that it *can* be useful if you know how to use it. I know what you mean.... we don't use the Hibernate cache at all. And I started out having all mappings (POJOs) generated by Eclipse. They worked quite well (including composite PKs), we did have some pitfalls though and over time (like two years or so) I have eliminated one after the other. Now I know how to use Hibernate properly, and that's fine. I like the fact that I can work with objects instead of SQL result sets. I'm used to it, I guess. Had Hibernate not come up, I would have solved the SQL handling for myself, over the years, just the same. So - I guess it's just not much more than a coincidence!
Paul Rivers
"No one thinks of using SVN again." I bet several people do, it's just easier to deal with GIT's added complexity than it is to argue about it more.
Derek
The new people on the team just show how to use GIT. If you want, I can show some of the advantages of GIT over SVN.
Angelo
I can just confirm I am in the same condition of Monica. As well the us eof Criteria disocurag ethe fully understanding of the schema and SQL, it s really easy with this approch find your self on really poor perfomance queries. The eager and lazy loading of the obect it s really hard to manage and drive to write really horrible code. It adds up complexity I definetelly prefer use Spring JDBC or JOOQ , becaus elive you the full controll your sql without adding complexity and maintence headcache to your project.
Angelo
absolutelly agree with you.
Angelo
Can you really relay on a framewirk where for enforce to walk torugh some entity you ar eforced to call a getter ? Or all the time you need to use the flushing mechanism , and what about batch update that still handled manually using HIbernate ? Second level cache sucks ... as as well the transactional model .
Polaco
usually hibernate generates very performant queries, but are design flaws in projects that leads to performance issues. Native queries can be much worse than hibernate generated ones if the developer does not take into account performance, index usage, optimizations and so on... So again blaming the framework / tool when instead are design/development errors.
Lê Anh Quân
Truly awesome article, one of the best I have read. I feel so sorry for my friends who are now still stick to these terrible technologies (Hibernate, EJB, Struts, IBM stuffs...). We have evolved and things don't have to be so bad. Anyway, you have successfully described the pain and sorry of Monica talking about her 4 years of career, and I know guys who have wasted more and still keep on wasting. How horrible. Monica is awake now, but my friends are still sleeping in those piles of sh**. The more pain is, it is not only 4 years, but also another year to clear her head of that total crap, and few more years of hard work to keep up with the other guys who hasn't chosen Hibernate from the start. Thank you very much for the article, I shared it, hopefully it will be the wake up call for some of my friends...
Lê Anh Quân
Terrible summary of the story, Hibernate is not the truck
chillenious
Hibernate/ ORM is a terrible choice for pretty much anything that isn't trivial. I've built many applications, small to large, over the years with it with many different teams, and always hated how eventually we'd run into hard-to-fix bugs and efficiency problems. For the last two years, I've been using jOOQ pretty much exclusively when doing Java, and it's been a night and day difference.
Dirk Dierickx
Thorben J. has made a great post on when to use Hibernate - http://www.thoughts-on-java.org/use-jpa-next-project/
Yegor
I believe John had to know everything about the framework and I think it's okay when there are various competency centers at companies which are being consulted about technologies they are competent at..
Yegor
is git really so complicated ? I've seen so many step-by-step tutorials that make all clear..
Miloš Milivojević
Indeed.
Francis Zabala
"Hibernate does not do that." <-- this.
Francis Zabala
It's funny how the last sentence reflects my own thoughts. I've been burned often enough to say not to use Hibernate to a point I'd rather use MyBatis. It's cumbersome yes but I like the idea of creating my own sql statements and it being closer to metal.
snedunuri
Although I no longer work in this area, I have found both the article and the comments very informative and entertaining to read. I first ran into the ORM problem almost 20 years ago when I battled with the then architect on the best approach to the problem (Aside: it seems to me Monica was delegating too much and not willing to either get into or deal with the technical issues of the project she was supposedly architecting). And I first used/encountered Hibernate in a project generating code from models about 12 years ago. its interesting to see many of the same problems are still around. Generally speaking, I am very suspicious of developers who say "XYZ is a big fat pig [no connection with Donald Trump here], lets just roll our own". And I have seen the consequences of this at least 3 times in my career, where sure initially you're flying high but pretty soon you get bogged down in dealing with the same issues that the framework/library/tool has already tackled. And what's more said framework/library/tool has hundreds of smart people working on it, so they can usually address issues and turn the thing around a lot faster than you with a couple of (already owverworked) developers can. Pretty soon you're slogging along with your own in-house solution which is now so far removed from the path taken by the rest of the world you're locked into your own solution for which you're going to have trouble hiring developers to maintain I also wanted to re-post Vadim's link to Fowler's article because Fowler writes so well and always gets to the gist of the problem nicely. http://martinfowler.com/bliki/OrmHate.html. The TL;DR version of what Fowler says is this: - The object/relational mapping problem is hard and tricky whether you do it yourself or have a tool do it - The essence of the problem isn't so much O to R but in-memory to R - A framework that allows me to avoid 80% of that [boilerplate code] is worthwhile even if it is only 80%. The problem is in me for pretending it's 100% when it isn't. - If all you're doing is reading from the db, then you might be better off avoiding the ORM and going directly to SQL - you may be able to sidestep the ORM issue altogether by either programming directly against a R model or using a non-R db as the backend cheers
Vin Patel
Christine, before you I din't see anyone mentioning role of code quality in success of a project. Not only that if Hibernate (or another tool) was chosen for the project for CRUD, reports, import etc. it's mandatory to prove that it'll work on production like data before hand. Also, as many others noted, without proper expertise on the team it seldom makes sense to employ new tool or technology.
Christine Slotty
Yeah..... it's kind of nonsense to argue about individual tools, sometimes. I still see people deliver untested functionality, nowadays, and ask myself what the heck they think they are, or why they think they should get money for what they've delivered..... in the end, what's important is, to 1. deliver the (tested!) functionality that was requested, 2. performance, 3. bugfreeness, 4. maintainability and some other quality measures. Of course it can make a nice talk, talking about advantages and disadvantages of a tool, but first of all, a tool gets the job done. And if not, it's not an "appropriate tool" at all and shouldn't even be discussed.
Gustavo Freitas
"Filling" the gap of impedance mismatch comes with a cost of having to learn two things: Hibernate being the overcomplicated one. Not to mention the numerous problems with attach/detach problems, semantics, etc. To use Hibernate you must first "MVP" your idea, then look for the gaps and see if it is exactly what your business demands. It can take some time.
Gustavo Freitas
Not too much Monicas around. Hmmm, I believe you're John. Right? :)
Gustavo Freitas
A few years ago I worked as an architect in a project and we had a similar situation. Our co-workers knew much pure SQL and Postgres. We were hiring new people, coming from different companies, used to JPA and Hibernate. We thought: why are we gonna lose the expertise from one over another? No, we must go with a hybrid solution. Hibernate for simple and trivial things, the CRUD side and queries developers judged to be clear written (code review is a plus). For our SQL experts - MyBatis. We could work together without any major problems and the knowledge we could transfer to each other was huge.
Vlad Mihalcea
No. I'm Vlad from the Hibernate team.
Gustavo Freitas
Obviously, I'm kidding. I can see you're a skilled Hibernate guy.
Vlad Mihalcea
Thanks. This article reminds me of this blog post that I wrote 3 years ago https://vladmihalcea.com/2013/11/21/why-i-never-blame-open-source-projects/
Alexander Fradiani
This article is great and I find even more interesting these comments. Vlad, let's say you have to manage a new team for a new project, with mixed skilled and average-like developers with different backgrounds in web/desktop/mobile development. How much time approximately you think it could take them to learn and use efficiently the Hibernate framework before they are actually able to use it correctly in the project? We can assume an MVP product with standard business-logic with scalability expectations in the future.
Vlad Mihalcea
I have a book called High-Performance Java Persistence: https://leanpub.com/high-performance-java-persistence After reading it, every one is the team will have a good understanding of what they need to do, and especially what they should never do with JDBC, JPA, Hibernate, and the most well-known RDBMS: Oracle, SQL Server, MySQL and PostgreSQL.
comments powered by Disqus
Subscribe
The #1 Blog for Engineers
Get the latest content first.
No spam. Just great engineering and design posts.
The #1 Blog for Engineers
Get the latest content first.
Thank you for subscribing!
You can edit your subscription preferences here.
Trending articles
Relevant technologies
About the author
Grzegorz Gajos
Java Developer
Grzegorz is a software architect with an international consulting and programming background. He's a co-founder and technical adviser for Open Tangerine software house. He also works as a software quality evangelist. Grzegorz is personable, communicates well, and has worked in teams of all sizes.