Haha, just stumbled across this. It's funny to see, a whole three years after the end of the Persistence Wars, and in the face of the incredible success of JPA in almost every corner of Java development, that the conspiracy theorists are still out there, darkly hinting that commercial organisations like Oracle, IBM, RedHat ... have their own vested interest in RDBMS technologies, or in selling application servers
.
As if the old JDO vendors weren't commercial organizations
, or weren't selling their own technologies in which they had a vested interest
.
Well, look here, JPA won. Get over it. It won because it was a better-written specification, with a better feature set. It was written by serious people with an understanding of the marketplace, not by scary Unabomber types with beards. It had a simpler set of APIs and a simpler lifecycle model. It revolutionized O/R mapping by introducing the first annotation-based mapping layer. It was truly integrated with the EE5 environment. It had better support for detached objects, and a more flexible model for handling graphs of persistent objects. It concentrated on defining user-visible semantics, not implementation. But, just as importantly, it left out all kinds of useless junk that JDO threw in. The measure of a good spec is not only what it puts in, but also what it leaves out, and what it leaves for tomorrow.
It doesn't help to screech that your spec has a bigger feature set, not unless you can prove that those features are useful, and well-designed.
Now that JPA2 is introducing great new things like a truly typesafe query API (instead of the totally half-assed fetch profiles
stuff in JDO2) and a runtime-accessible metamodel, can't we all just agree that things turned out pretty well, in the end?
So.. let me get this straight.. According to them we (Red Hat) couldn't sell app servers with JDO, but we could with JPA.. Does that mean they admit JDO sucks?
I suppose it's theoretically possible that they believe JDO only sucks in an appserver.
In which case the only point of disagreement between them and the rest of the world would be over whether JDO sucks out of an appserver.
From the faq:
This is so true! Spreadsheets abstracted with JDO is superior in every way to an RDBMS!
I think you are on to something, but since they mentioned JPA was created to push RDBMS, it seems they must also agree that JDO sucks outside of an appserver when an RDBMS is involved.
So funny how arrogant and blind you guys are. Masturbatory self-satisfaction rocks. Will you publish the user feedback received today at the JPA user group about these wonderful type-safe query APIs?
JPA is Hibernate. Oh no, it is Toplink. OK so let's standardize what we have in common. Blah blah blah. JPA is great because it does not specify most important things (locking, batch updates, multiple database connections, decent query language...). The only guy in the JPA committee is the guy from SAP.
Why do you guys still spend some time on killing the dead? Don't you have more important things to do like thinking about how to make JPA 3 more complete?
The measure of a good spec is not only what it puts in, but also what it leaves out, and WHAT IT LEAVES FOR TOMORROW. Ha ha. JPA is great because it can be greater later... Stupid.
The funny thing is that the rant seems out of touch with the current problems in JavaEE.
People want fewer framework choices and more simplicity in their JavaEE stack, IMHO. Why rehash an argument that's been won?
Indeed! It's definitely more fun than making tin foil hats.
If JDO sucks so bad, why is it used on AppEngine?
It's really getting tiresome to hear you JBoss guys bashing anything outside the mainstream JEE and expecting everyone to standardize their software accordingly.
I don't intend to talk about JPA vs. JDO since I don't have real world experience with JDO, but I worked with Hibernate and JPA enough to say that it is not the ultimate solution for any data access requirement, and can be a real pain to use in web applications.
The idea of persistence context when forced on the developer is very wrong in my opinion. What if I want to just have the ORM tool do the mapping and SQL generation, but not manage my objects? It all works fine in the unit tests, but when I use it in a web application I get all sorts of exceptions for transient object and lazy initialization, and in order to overcome them I need to either write a lot more code or use a tool like Seam or Spring Webflow, when all I wanted from the beginning is not having the ORM messing with my object identity and state. That's why I started my latest project with iBatis, after being burnt by Hibernate/JPA. I strongly suggest that the state management be made optional, and let the developers worry about that if they want. As I said Hibernate/JPA is great for the mapping, and I would use it if it were possible without the state management.
To say that JPA is better than other solutions just because it's part of the JEE5 spec is like saying JSF is better than all the other web frameworks because of the same reason. I doubt many will agree on that.
Er, so I shoudn't even respond to someone else saying nasty things about us, even when they actually mention the name of the company I work for? Did you even read the linked article? Sorry, but I would get very bored of living with the rule that everyone else is allowed to respond to things I write, but I'm not allowed to respond to things other people write, because I work for JBoss :-)
Precisely how many times do I have to read that JDO is better than JPA but JPA is the standard because Oracle/JBoss/whoever are big evil companies trying to sell relational databases before it's OK for me to point out that this is a load of bunk?
Sure, persistence context management can be a pain in some architectures - though, as you've noticed, it isn't when you have a decent framework that manages the persistence context for you. But, unfortunately, persistence contexts are necessary.
Let's go back to basics. What's a persistence context? Well, it's just a map from id (primary key) to an object that holds the state associated with that primary key.
If I don't have a persistence context, what I'm saying is that in a particular execution context (transaction, request, conversation, whatever) I can have multiple objects representing the same row of the database. That is, if I happen to run two queries that return the same id, or return objects associated with the same id, then there will be two objects representing the row in the database with that id. This is a fundamentally broken state model that opens you up to all kinds of subtle bugs that are difficult to test for. The notion that a transaction would not see its own changes sounds waaay exotic to me.
Are there any other alternatives to the transaction/conversation scoped persistence contexts in JPA? Well, I have seen some architectures which try to use a single persistence context for the whole process, but that is fundamentally unscalable, requiring in-memory locking to prevent concurrent transactions from seeing each other's changes, deadlock detection, the works. No thanks.
Yes, it is probably theoretically possible to combine the notion of a single persistence context for the whole process with some really heavy-duty bytecode magic so that the state seen in each instance would depend upon the thread accessing the instance, and different transactions would see their own changes, even when accessing the same instance. (Someday I would like to experiment with an architecture like that, just not in Java.) This might solve some of the problems with persistence context management, but it definitely doesn't solve them all. You would still need a merge() operation if you wanted to work with detached objects. And it would be even more difficult to identify which objects you wanted to detach and serialize. Whatever you try to do like this, you'll run into the problem that Java doesn't have any kind of Smalltalk-style becomes() operation
And that's why persistence contexts is one of the things that JPA and JDO actually agree on!
... if I happen to run two queries that return the same id, or return objects associated with the same id, then there will be two objects representing the row in the database with that id. This is a fundamentally broken state model that opens you up to all kinds of subtle bugs that are difficult to test for. The notion that a transaction would not see its own changes sounds waaay exotic to me.
</quote>
First, I'm not against JPA or JDO or anything else... It just happens that I'm using JPA...
Anyway, there is a tool called PowerBuilder and since late 1980 it has so-called DataWindow which handles this easy. Hmm...
And precisely how is DataWindow not a persistence context?
Personally, I take exception at you darkly hinting that beards are evil... ;-)
Now this is a good thread! JDO, JPA, EJB ... whatever.
Personally, I like JPA (once again, thanks to Gavin for the introduction of Hibernate). I have had great success with both Hibernate/EJB3 and JPA with Web apps. I think a big mistake many people make is trying to do to much directly with the entity objects. My big problem right now is that I have to try to deal with yet another layer called the pattern from Domain-Driven Design, ugh. Can we insert another layer that will solve all of the worlds problems?
I like JPA a lot, but one think I really do not like is that the TCK is private, and when you find a inconsistency between 2 JPA implementations, it is not as easy as it should be to propose a fix for the problem to prevent different implementations from behaving different.
I mean, what is the point of making people sign an NDA for the TCK? That only bring obscurity to a process that should be transparent.