JPA not so good after all?

At jfokus I listened to a guy from Oracle talking about JPA 2.0. I guess JPA makes sense from a database perspective. Today I stumbled over this interesting article on the subject. Billy Newport points out that JPA only cares for parts of our needs for persistence. Data stored in web server sessions or in caches are typically put in simple hash tables. JPA could be split into one part that cares for persistence anywhere and another part that cares specifically for persistence into a relational database. Interesting thoughts indeed. On the other hand - what is it that is so bad about SQL?


Old comments

2009-02-13Hardy Ferentschik
Wanted to comment on this one for days, but just kept forgetting. Just read the original post and must say that I am actually not quite following. What is really his solution here? One thing to say that the spec should be split, but how? And in my world I can use normal POJOs for a long time in frontend.
I agree however, that JPA2 really offer nothing really new. It seems just to plug some holes and seems to target especially people having to integrate with legacy databases. Often these databases are so screwed up that you wonder whether you should allow them to use JPA against them or not ;-)
2009-02-14Fredrik Rubensson
I think his point is that there should be a standard for persisting POJOs anywhere but he never really get into how. For a cache or a session - a normal POJO object structure is probably fine all the time. Serializing to XML (a kind of persistence perhaps?) has its own standard (JAXB) and so has serializing to a web page (JSF). A POJO that is used in many situations will turn out to have loads of annotations. My point is (although I never stated it....) that Java is heading for more and more complexity whereas it should go the opposite way. For some reason the industry seems to think that XML is a good thing and real code is a bad thing. It should be the other way around... Whoa - got a bit carried away there. Back to JPA. I think JPA probably is great for new databases but rather unusable for legacy databases. But I would prefer to use SQL with Spring for any solution - new or old.