I think his point is that there should be a standa...

2009-02-14T22:56:00.000+01:00

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.

Wanted to comment on this one for days, but just k...

2009-02-13T15:52:00.000+01:00

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

Comments on high level bits: JPA not so good after all?

I think his point is that there should be a standa...

Wanted to comment on this one for days, but just k...