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

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?

Unreliable

Answer 1

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.

Roussillon

toolkit, nice and short. Another point worth mentioning is that JPA doesn't prevent from using implementation specific features if necessary. That means that JPA lets you use any Hibernate feature when Hibernate is an implementation. – Petrolatum

What would be the advantages of using JPA if I need some specific feature from Hibernate? – Copacetic

An important note that should be added: While JPA and JDO both have excellent support for RDBMSes JDO is 'datastore' agnostic and so is not limited to the RDBMS world. With the ground swell of NoSQL at the moment a person would be wise to consider using a persistence standard that avoids locking their apps to the traditional *SQL world. JDO applications can easily be deployed non RDBMS datastores. Full list of supported datastores can be found at: datanucleus.org/products/accessplatform/datastores.html – Tin

@Golfman why choose based on what might happen? There's nothing to stop you from rolling in something else later if you ever did end up needing NoSQL support... KISS – Mofette

@Bruno - when you are using non-Hibernate-specific parts of Hibernate, you are using JPA. Obviously, the advantage of restricting yourself to pure JPA is that you can switch to another JPA implementation more easily. – Abstractionism

Funnily enough, the selling point of JDO has always been that it was datastore agnostic, so you could switch to a OO database. Did it happen? No, for a lot of obvious reasons. Same player, shoot again: with JDO, you could switch to a NoSQL database. Will it happen? I bet it won't and I can't wait for the NoSQL soufflé to fall. But, sure, you can switch to a spreadsheet datastore,... – Seguidilla

@Roussillon do you think that your recommendations would change now that JPA 2 is out? I haven't used it myself but the typesafe criteria API looks pretty nice. – Sullins

@TM - "keeping it simple" is always preferred, but if you're implying that JDO is "less simple" than JPA...huh? More freedom and openness is always better, why throw away extra flexibility you get essentially for free (without extra work)? @Pascal - Yes you're not likely to swap a completed app's db from an RDBMS to something else. But why limit your skill set and experience to an RDBMS-only spec when you could learn a spec that gives you more choices on the 'next big project'? If you have a choice of which to gain expertise in, you might as well choose the more flexible skill set. – Forborne

@Stephen C - I think Bruno was asking what advantage JPA presents when using Hibernate-specific features (since this was alleged to be a good thing about JPA). Seems like a good question to me, because I can't imagine any benefit, other than deceptively allowing some vendors or libraries the ability to claim they "implement a standard". Or, should I say, "implement an incomplete standard"? I mean come on: "JPA is a good spec because if you're using it, you don't have to use it!" ...What? Using a specification just for the sake of using a specification is rubbish. – Forborne

@Stephen C - Anyway, I think understand your point, but the original comment prompting the question was just silly the way it was put forth. – Forborne

@Crusader Not saying that JDO is simpler than JPA or vice versa. I'm just implying that worrying about NoSQL support when if you have nothing to suggest that you "might need it" is a waste. – Mofette

Is JDO still around? Still used for a specification? – Sunbathe

Answer 2

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

Tin

And as we all know, enhancement is precisely why JDO has been so massively adopted! – Seguidilla

The well publicized FUD and astroturfing executed by key Hibernate players in the early days in relation to JDO is nothing short of dishonest and disgusting and no doubt had some affect on JDO's adoption. These days developers know that byte code enhancement is not a problem at all and often use it for many different purposes other than persistence. The new ASM byte code enhancement library is so lightning fast you don't even have time to take a breath before it's done. – Tin

The failure of JDO was predicted since the start (javalobby.org/forums/thread.jspa?forumID=46&threadID=1326) and before Hibernate so you can't blame Hibernate for that. Hibernate/Toplink succeeded where Sun and JDO players (and their OODBMS) failed because they were better answers at that time, not because of marketing and FUD. Period. Who cares if ASM is blazing fast today, it wasn't there 5+ years ago, when needed and JDO simply lost the battle. JDO is conceptually superior? Too bad, it failed at having a winner implementation on time (and won't come back because of JPA). – Seguidilla

To illustrate my words (yet another post that illustrates the pain that people were feeling during development or why Hibernate did win the battle): mail-archive.com/[email protected]/…. It seems obvious to me that reflection/cglib was a practical answer to people's problems (and people don't care if an API is conceptually superior if it's a pain to use) and I don't see any Hibernate key players here, just users. So at the end I wonder who is spreading FUD actually... – Seguidilla

Well this is certainly not like the old days where there would have been at least 17 different pro Hibernate FUD posts (yet only coming from 3 different IP addresses. Do the maths people =) ). – Tin

"and people don't care if an API is conceptually superior if it's a pain to use". It sounds like you've never enlightened yourself by actually using JDO because if you had you wouldn't say it's a pain to use. After using Hibernate I switched "to JDO" because I found the API easier to use and found JDOs 'transparent persistence' much less of a pain than what Hibernate's reflection/cglib solution had to offer. Here's some details for those interested in discerning FUD from facts: datanucleus.org/products/accessplatform_2_0/… – Tin

Taking my sentence out of its context is weak sauce. I was clearly referring to the mail cited as reference and, at that time, JDO was a pain (and I did experiment this pain myself), Hibernate was a better answer and this is why it took the market, not because of 17 pro Hibernate posts (what a joke!) nor marketing. Not recognizing this is ridiculous (especially since you're repeating yourself - yes I've read your posts on TSS and so on). And because my clients are using JPA now (they don't even think about JDO), because they want to use a widely used/supported/tested JPA provider, so do I. – Seguidilla

Pain is a very subjective thing: While some people might regard waiting an extra 1 or 2 seconds after a compile for the enhancement process back then (these days it's an order of magnitude faster than it was) as painful others might see restrictions and constraints on their design/modeling and coding when using a persistence solution that isn't 100% transparent a more significant pain with, depending on the expressiveness and complexity of their domain model, more time committed to working around the imposed constraints. I personally found that more painful. Different pain for different people – Tin

@Golfman maybe it's just Kodo, but I really hate JDO, and so does every single one of my coworkers. It's to the point where half of them would rather use straight JDBC. And just to be clear, no one hates it because of the extra compile step. They hate it because it's a pain to write code with and a pain to optimize queries with. Just my personal experience. – Mofette

Does this answer require an update? – Safeguard

Answer 3

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.

Omora

I'd really like you to elaborate your points instead of repeating things like a parrot (yes, that's exactly what you are doing). According to your other posts, you don't have much experience with Object Persistence in general and, I'm not really sure you ever used neither Hibernate, nor JPA, nor JDO. So, at the end, you're just turning this thread a bit more into desperate advertising, reusing others (sometimes biased and invalid) arguments. – Seguidilla

Actually, just like I said, I was just giving my impressions of what I had discovered while trying to pick a solution. Yes I am a beginner in Java, why should that be that relavent? You, on the other hand have posted a number of times stating your opinion that JDO is dead without offering any facts or proof to substantiate it and not acknowledging the technical areas where JDO is clearly superior. You obviously have something personal against JDO/Datanucleus and are using these threads as a means to perpetuate your anti-JDO stance. – Omora

Tom, just look at Google Trends, or indeed.com, and tell me if JDO is a success from an adoption point of view (adoption is IMO what makes a standard alive, not the number of versions of the spec). I have used many ORMs since 2002, including Toplink, JDO 1.0, Hibernate and JPA and I don't feel sorry to say that JDO 1.0 has been an horrible experience, which is precisely why Hibernate took the market of RDBMS persistence. And whether you like Hibernate approach or not, standardizing a widely adopted solution has been a good move for Java EE and I'm happy it happened. – Seguidilla

So yes, JPA is younger and has less (I'm not denying that), but I am satisfied with it for RDBMS persistence and prefer its API, query language, ease of use, simplicity, etc over JDO. And I believe that this is what makes JPA successful and I don't feel guilty for writing it. Likewise, you're free to use JDO and I don't have any problem with people keeping JDO under artificial respiration. However, I'm tired by the conspiracy theorists and those using SO for advertising should read the FAQ again. Personally, I'm not affiliated, I'm just a user. – Seguidilla

Pascal - you are arguing yourself into a corner here. I think you are missing the point of the Advertising section of the FAQ. The OP asked for opinions about 2 technologies. It is inviting those supporting either side to come forward and present their constructive criticisms/recommendations. For Andy/Datanucleus and other JDO users to highlight JDO positives and defend against criticisms is no more advertising than someone else here recommending to use hibernate. – Omora

You might do well to refer to the section of the FAQ that says 'Be Nice' for your posts on this topic have been accusatorial, confrontational or plain rude. Your first was a sarcastic comment about enhancement. Second; a rant on the difficulties of early implementations and is no longer relevant. Third was a childish mocking and insult to those who might prefer not to use RDBMS. Fourth was sarcastic mocking of someone who has different views to you. Fifth was an attack; calling me a parrot. Do you consider this 'Being nice'? – Omora

If you had a horrible experience with JDO, then explain what was horrible, acknowledge that it was with an earlier version and things may have been improved since then. You need to also recognise that others may have different needs to you. Just because you are 'satisfied' with JPA and want to use a RDBMS doesn’t mean that others are. Maybe in your haste to increase your reputation you have lost sight of what that reputation is there to award? ps. As a developer you should really be interested in the wellbeing of such projects as that is what drives innovation and reduces vendor-lock in. – Omora

This will be my final comment. 1. The point about advertising was not specific to this question. 2. If you think the opinions I expressed are inappropriate, report them. But I fully assume and I don't see anything dishonest in what I said (contrarily to some comments to which I responded). 3. No, sorry, I'm not going to summarize 8+ years of persistence war to explain why I'm not using JDO today, that would be too long. And what I meant is that (most) users, not only me, are satisfied with a RDBMS datastore (Google offering paid SQL hosting is another hint). – Seguidilla

4. I don't see what my participation to SO has to do with all this. I like problem solving, sharing solutions, etc but still have opinions. Do I need to add that rep isn't real? 5. I have no problem with competition (it's good for users). However, the "Hibernate/JPA/JBoss is evil" attitude is irritating me. I'm happy of what they did to Java. 6. I'm done now, if you want more details, there are 7 years of threads to read on TSS and all over the net. – Seguidilla

This will be my final response :) .. 1. If it wasn't relavent to question why raise it? 2. I never questioned your honesty, I said you were not being nice to other posters and that you contradicted yourself. 3. no one suggested you summarize 8+ years - but back up your statements with facts and examples rather than subjective statements that are likely to offend. 5. Where are the 'hibernate/jpa/jboss is evil' attitude on this post? I dont see it. I only see your anti-JDO comments. – Omora

Funny stuff - one thing Pascal doesn't seem to understand is that being a market leader in anything doesn't end market competition. It doesn't matter if JPA "beat" JDO historically, even if due to past issues w/JDO. If JDO is better now, as comparisons seem to demonstrate, the primary thing keeping JPA popular is popularity itself (and possibly certain large vendors if you agree with that reasoning). If that's the case, there are few (if any) good reasons to tell people that "JDO is dead" or not to use JDO. Like what happened w/Apple--tides can shift if you aren't the top performer. – Forborne

I would like the warm fuzzy feeling of not having to rewrite all my code again. That said, your post started out informative and ended up showing bias. – Bereft

JPA may be more popular than JDO but it's just like Hyundai and Toyota cars are more popular than Mercedes, Audi, BMW & Volkswagen cars. What would you rather drive? The major difference here is that with cars you have to fork out a whole lot more cash to buy the well engineered, high performance, structurally safer, longer lasting makes but with free, open source implementations of JPA & JDO you can choose to drive the better quality version so long as you don't have a fixation on "buying the most popular car". Some "sheeple" have a problem with decisions like that. I don't. – Tin

"support in favour of JPA is that it doesn't use bytecode enhancement". Now let me see ... EclipseLink, OpenJPA, DataNucleus JPA and Hibernate ALL use bytcode enhancement these days. So that's this one ruled out – Scurlock

Answer 4

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).

Electroluminescence

this is clearly anti- object-relational mapping (ORM) choice driven by large user and code base accumulated since ODBC times (early 90s) (read legacy). There is no reason not to use JDBC (with or without Spring) unless you choose to move on and use ORM framework. Think of those people who one day decided to ditch FORTRAN to use C or Pascal. – Petrolatum

@grigory - I speak with much experience of wasting days trying to understand Hibernate issues, such as cascading updates/deletes, ridiculously inefficient query structures etc. ORM solutions are a "quick-win" for those with insufficient understanding of relational databases. As such, it is unlikely that knowledge of Hibernate alone will result in a good end-product. It's my experience that, over the project lifecycle, Hibernate (and ORM by extension) costs more time than it saves – Electroluminescence

sorry that you had such poor experience with Hibernate. I am coming from heavy database/SQL/stored procedure/JDBC school myself. I can't say I am convert - every technology above still has a place to be. But for general purpose Java 3-tier application (no matter what size) first choice is an ORM technology - preferably JPA 2. Others are to be considered based on such factors legacy code, integration, expertise, batch-heavy requirements, real-time performance etc. which may steer (or may not) approach towards different database technology stack. – Petrolatum

I completely disagree with "quick-win" definition above - just grab Hibernate in Action (#97229) (and it's JPA 1, with JPA 2 it gets only better) to fully understand power and coverage this technology has. – Petrolatum

@oxbow_lakes: I'm with you on this. I'm a developer DBA who is helping Hibernate using Java guys to troubleshoot this black box. Hibernate speeds development of course, but you simply shift the bottleneck. ORMs have their place (a means, not the end) but respect the RDBMS. Mind you, I'll always have a job if folk want to use ORMs... – Choker

I shared the same experiences as @oxbow. I had a relatively simple object graph that was editable by a Swing GUI. Sometimes it would work and then after a few minor code changes, it stopped working. I know Java and SQL very well. Hibernate gave misleading errors and sometimes even ate the exceptions altogether. During my troubleshooting, I read horror stories of Many-To-One mappings deleting data from the database. That's just too scary for me. – Leupold

@oxbow. I want to learn Spring. Where do I start? – Leupold

@Leupold - how about here: static.springsource.org/spring/docs/3.0.x/… – Electroluminescence

I did a little research and Spring no longer recommends Spring DAO's (static.springsource.org/spring/docs/3.0.x/…): "The recommended integration style is to code DAOs against plain Hibernate, JPA, and JDO APIs. The older style of using Spring's DAO templates is no longer recommended;"...Is this what you were recommending? If so, why do they not recommend it? – Leupold

Don't use Hibernate for very complex data structures with many joins and cascades. I've done that and seen the issues. However, for a simple application JPA/Hibernate is by far the fastest way to get rolling. I've never enjoyed spending hours writing boilerplate Spring RowMapper code. This is why we invented computers, to do this mapping automagically. For such an application RowMappers are just a boon if you're working by the hour. – Maund

@Leupold : i understand the passage you're quoting a bit differently than you. They're talking about how one should "integrate" ORMs (eg : using Spring Hibernate Template or not). Not whether you should or should not use ORM vs raw JDBC. – Pennypennyaliner

@Leupold - You did misunderstand. Your quote mentions the "recommended integration style" while the recommendation in this answer is to not integrate with an ORM at all. – Saimon

Answer 5

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

Shannashannah

People are most certainly using it, as evidenced by the many users that DataNucleus has, never mind Xcalia, Kodo. You miss the basic idea that JDO and JPA are not filling the same market. JPA is exclusively RDBMS. JDO is datastore agnostic and is used for RDBMS, but also LDAP, XML, Excel, OODBMs etc – Shannashannah

I like the non-RDBMS factor, particularly with the increase in popularity of non-RDBMS solutions, it's a big deal. This means that if JPA doesn't evolve fast enough, availability of a "more open" and flexible alternative (JDO) means that JPA's popularity will be trending downwards, out of necessity. Never mind the technical arguments that JDO is more complete, superior, mature, or whatever else--it won't be a matter of preference. It makes sense that RDBMS vendors are behaving suspiciously--the days of RDBMS market dominance may be coming to an end. – Forborne

We're still using JDO/DataNucleus in 2019! It's now up to Version 5.x and still beats Hibernate for developer productivity and runtime performance. Recently I had to do some consulting on a large web app using Hibernate and was reminded of the pain I suffered when I was an active HIbernate user and promoter many years ago, A team lead did not believe me when I told her that her BLOB field was always eagerly fetched even though it was marked as lazy fetched. The complete lack of "under the hood" knowledge by an "experienced" self proclaimed Hibernate expert was sadly disturbing but expected. – Tin

Answer 6

JDO is having advanced features than JPA see http://db.apache.org/jdo/jdo_v_jpa.html

Belloir

Very true! But no one seems to know it... – Boner

Answer 7

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).

Oodles

Answer 8

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.

Townspeople

+1 for DataNucleus, not for the answer. – Bosworth

Answer 9

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.

Tin

Or you use another (fine) implementation with a much bigger and consequently more responsive community. Yes, some people do care of that too. – Seguidilla

That's a good point you make. When people use the implementation you refer to the need for lots of support and frequent explanations of 'best practice workarounds' and 'how do I make it perform fast and use less memory' will be most important =] – Tin

And you talk about FUD >:) Funny. – Seguidilla

Your comment seems to presume that I haven't used both Hibernate and JDO. – Tin

This thread seems to have an awful lot of references from a couple people to how great DataNucleus is. Please don't use this place as your advertising platform. – Mofette

Nothing surprising from Golfman who is pasting the same desperate marketing stuff over and over in every thread involving JPA or DataNucleus (that he is using since 1996, before it even existed!). – Seguidilla

Hay guise what's going on in here? – Phosphoresce

Whoops! :) That was supposed to be 2006! Still debugging my time machine in my spare time. – Tin

Golfman, isn't it possible to write a custom classloader that enhances the byecode just brfore loading thr classes. Why is it necessary for the bytecode enhacement to be done at compile time? – Didier

Enhancement can be done post-compile or runtime, as per the Datanucleus docs – Shannashannah

I just found an interesting performance comparison between JPA implementations (DataNucleus is both a JDO and JPA implementation). While Hibernate does ok with a 1000 inserts into a single flat file DataNucleus really excels when you persist objects with relationships to other objects - you know, kind of like in a real application :) Here's the link: s3-eu-west-1.amazonaws.com/presentations2012/… – Tin

Answer 10

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.

Suggestion

As far as I can tell, JPOX changed name to DataNucleus (and has had releases since then). – Mario

Think you'll actually find that DataNucleus has way less open bugs than the other software to which you refer. Think you'll also find that DataNucleus development is reducing numbers of bugs at a faster rate than that other software too. – Shannashannah

Answer 11

I made a sample WebApp in May 2012 that uses JDO 3.0 & 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)

Nonresistance