Hibernate vs JPA vs JDO - pros and cons of each

Question

I m familiar with ORM as a concept  and I ve even used nHibernate several years ago for a  NET project  however  I haven t kept up with the topic of ORM in Java and haven t had a chance to use any of these tools   But  now I may have the chance to begin to use some ORM tools for one of our applications  in an attempt to move away from a series of legacy web services   I m having a hard time telling the difference betweeen the JPA spec  what you get with the Hibernate library itself  and what JDO has to offer   So  I understand that this question is a bit open-ended  but I was hoping to get some opinions on    What are the pros and cons of each  Which would you suggest for a new project  Are there certain conditions when it would make sense to use one framework vs the other

User · Answer

I ve used Hibernate  JPA implementation  and JPOX  JDO implementation  in the same project   JPOX worked ok  but ran into bugs fairly quickly  there where some Java 5 language features it did not support at the time   It had problems playing nice with XA transactions   I was generating the database schema from the JDO objects   It wanted to connect to a database every time which is annoying if your Oracle connection happens not be working   We then switched to Hibernate   We toyed around with just using pure JPA for awhile  but we needed to use some of the Hibernate specific features to do the mapping   Running the same code on multiple databases is very easy   Hibernate seems to cache objects aggressively or just have strange caching behavior at times  There are a few DDL constructs Hibernate can not handle and so they are defined in an additional file that is run to initialize the database   When I ve run into a Hibernate problem there are often many people that have run into the same problem which makes googling for solutions easier   Finally  Hibernate seems to be well designed and reliable   Some other responders have suggested just using SQL   The real killer use case for object relational mapping is testing and development   The databases that are built to handle large volumes of data are typically expensive and or they are difficult to install   They are difficult to test with   There are plenty of in-memory Java databases that can be used to test with  but are typically useless for production   Being able to use a real  but limited database  will increase development productivity and code reliability

User · Answer

Make sure you evaluate the DataNucleus implementation of JDO  We started out with Hibernate because it appeared to be so popular but pretty soon realized that it s not a 100  transparent persistence solution  There are too many caveats and the documentation is full of  if you have this situation then you must write your code like this  that took away the fun of freely modeling and coding however we want  JDO has never caused me to adjust my code or my model to get it to  work properly   I can just design and code simple POJOs as if I was going to use them  in memory  only  yet I can persist them transparently   The other advantage of JDO DataNucleus over hibernate is that it doesn t have all the run time reflection overhead and is more memory efficient because it uses build time byte code enhancement  maybe add 1 sec to your build time for a large project  rather than hibernate s run time reflection powered proxy pattern   Another thing you might find annoying with Hibernate is that a reference you have to what you think is the object    it s often a  proxy  for the object  Without the benefit of byte code enhancement the proxy pattern is required to allow on demand loading  i e  avoid pulling in your entire object graph when you pull in a top level object   Be prepared to override equals and hashcode because the object you think you re referencing is often just a proxy for that object    Here s an example of frustrations you ll get with Hibernate that you won t get with JDO   http   blog andrewbeacock com 2008 08 how-to-implement-hibernate-safe-equals html http   burtbeckwith com blog  p 53  If you like coding to  workarounds  then  sure  Hibernate is for you  If you appreciate clean  pure  object oriented  model driven development where you spend all your time on modeling  design and coding and none of it on ugly workarounds then spend a few hours evaluating JDO DataNucleus  The hours invested will be repaid a thousand fold   Update Feb 2017  For quite some time now DataNucleus  implements the JPA persistence standard in addition to the JDO persistence standard so porting existing JPA projects from Hibernate to DataNucleus should be very straight forward and you can get all of the above mentioned benefits of DataNucleus with very little code change  if any  So in terms of the question  the choice of a particular standard  JPA  RDBMS only  vs JDO  RDBMS   No SQL   ODBMSes   others   DataNucleus supports both  Hibernate is restricted to JPA only   Performance of Hibernate DB updates  Another issue to consider when choosing an ORM is the efficiency of its dirty checking mechanism - that becomes very important when it needs to construct the SQL to update the objects that have changed in the current transaction - especially when there are a lot of objects  There is a detailed technical description of Hibernate s dirty checking mechanism in this SO answer   JPA with HIBERNATE insert very slow

User · Answer

JDO is dead   JDO is not dead actually so please check your facts  JDO 2 2 was released in Oct 2008 JDO 2 3 is under development   This is developed openly  under Apache  More releases than JPA has had  and its ORM specification is still in advance of even the JPA2 proposed features

User · Answer

I have recently evaluated and picked a persistence framework for a java project and my findings are as follows   What I am seeing is that the support in favour of JDO is primarily    you can use non-sql datasources  db4o  hbase  ldap  bigtable  couchdb  plugins for cassandra  etc  you can easily switch from an sql to non-sql datasource and vice-versa  no proxy objects and therefore less pain with regards to hashcode   and equals   implementations more POJO and hence less workarounds required supports more relationship and field types   and the support in favour of JPA is primarily    more popular jdo is dead doesnt use bytecode enhancement   I am seeing a lot of pro-JPA posts from JPA developers who have clearly not used JDO Datanucleus offering weak arguments for not using JDO   I am also seeing a lot of posts from JDO users who have migrated to JDO and are much happier as a result   In respect of JPA being more popular  it seems that this is due in part due to RDBMS vendor support rather than it being technically superior   Sounds like VHS Betamax to me    JDO and it s reference implementation Datanucleus is clearly not dead  as shown by Google s adoption of it for GAE and active development on the source-code  http   sourceforge net projects datanucleus     I have seen a number of complaints about JDO due to bytecode enhancement  but no explanation yet for why it is bad    In fact  in a world that is becoming more and more obsessed by NoSQL solutions  JDO  and the datanucleus implementation  seems a much safer bet   I have just started using JDO Datanucleus and have it set up so that I can switch easily between using db4o and mysql  It s helpful for rapid development to use db4o and not have to worry too much about the DB schema and then  once the schema is stabilised to deploy to a database  I also feel confident that later on  I could deploy all part of my application to GAE or take advantage of distributed storage map-reduce a la hbase  hadoop   cassandra without too much refactoring   I found the initial hurdle of getting started with Datanucleus a little tricky - The documentation on the datanucleus website is a little hard to get into - the tutorials are not as easily to follow as I would have liked  Having said that  the more detailed documentation on the API and mapping is very good once you get past the initial learning curve   The answer is  it depends what you want  I would rather have cleaner code  no-vendor-lock-in  more pojo-orientated  nosql options verses more-popular    If you want the warm fussy feeling that you are doing the same as the majority of other developers sheep  choose JPA hibernate  If you want to lead in your field  test drive  JDO Datanucleus and make your own mind up

User · Answer

Anyone who says that JDO is dead is an astroturfing FUD monger and they know it   JDO is alive and well  The specification is still more powerful  mature and advanced than the much younger and constrained JPA   If you want to limit yourself to only what s available in the JPA standard you can write to JPA and use DataNucleus as a high performance  more transparent persistence implementation than the other implementations of JPA  Of course DataNucleus also implements the JDO standard if you want the flexibility and efficiency of modeling that JDO brings

User · Answer

I made a sample WebApp in May 2012 that uses JDO 3 0  amp  DataNucleus 3 0 - take a look how clean it is  https   github com TorbenVesterager BadAssWebApp  Okay maybe it s a little bit too clean  because I use the POJOs both for the database and the JSON client  but it s fun     PS  Contains a few SuppressWarnings annotations  developed in IntelliJ 11

User · Answer

Which would you suggest for a new project    I would suggest neither  Use Spring DAO s JdbcTemplate together with StoredProcedure  RowMapper and RowCallbackHandler instead   My own personal experience with Hibernate is that the time saved up-front is more than offset by the endless days you will spend down the line trying to understand and debug issues like unexpected cascading update behaviour   If you are using a relational DB then the closer your code is to it  the more control you have  Spring s DAO layer allows fine control of the mapping layer  whilst removing the need for boilerplate code  Also  it integrates into Spring s transaction layer which means you can very easily add  via AOP  complicated transactional behaviour without this intruding into your code  of course  you get this with Hibernate too

User · Answer

I ve been looking into this myself and can t find a strong difference between the two  I think the big choice is in which implementation you use  For myself I ve been considering the DataNucleus platform as it is a data-store agnostic implementation of both

User · Answer

JDO is having advanced features than JPA see http   db apache org jdo jdo v jpa html

User · Answer

I am using JPA  OpenJPA implementation from Apache which is based on the KODO JDO codebase which is 5  years old and extremely fast reliable   IMHO anyone who tells you to bypass the specs is giving you bad advice  I put the time in and was definitely rewarded  With either JDO or JPA you can change vendors with minimal changes  JPA has orm mapping so we are talking less than a day to possibly change vendors   If you have 100  tables like I do this is huge  Plus you get built0in caching with cluster-wise cache evictions and its all good  SQL Jdbc is fine for high performance queries but transparent persistence is far superior for writing your algorithms and data input routines  I only have about 16 SQL queries in my whole system  50k  lines of code

User · Answer

Some notes    JDO and JPA are both specifications  not implementations  The idea is you can swap JPA implementations  if you restrict your code to use standard JPA only    Ditto for JDO   Hibernate can be used as one such implementation of JPA  However  Hibernate provides a native API  with features above and beyond that of JPA    IMO  I would recommend Hibernate     There have been some comments   questions about what you should do if you need to use Hibernate-specific features   There are many ways to look at this  but my advice would be    If you are not worried by the prospect of vendor tie-in  then make your choice between Hibernate  and other JPA and JDO implementations including the various vendor specific extensions in your decision making  If you are worried by the prospect of vendor tie-in  and you can t use JPA without resorting to vendor specific extensions  then don t use JPA    Ditto for JDO     In reality  you will probably need to trade-off how much you are worried by vendor tie-in versus how much you need those vendor specific extensions   And there are other factors too  like how well you   your staff know the respective technologies  how much the products will cost in licensing  and whose story you believe about what is going to happen in the future for JDO and JPA

[java] Hibernate vs JPA vs JDO - pros and cons of each?

Examples related to java

Examples related to hibernate

Examples related to orm

Examples related to jpa

Examples related to jdo