I am involved in a new project now and I am given the option to use either JPA (Hibernate implementation) or Hibernate. However, I can not tell why to chose one of them. I am personally accustomed to using Hibernate but I don't see JPA a lot different. What is your experience? What would be your choice in respect to project size and database complexity.

I have tried a little project with JPA and unfortunately, I have decided to come back to hibernate. There are some missing features with jpa (like having your own converter for a class) that made me come back to hibernate.

I also attended a webinar from bea tech lead on jpa and I remember that he mentioned that some point he did not agree with would not be corrected in next version because of backward compatibility.

Thus, if you can live with some minor problems, you will at least be j2ee compliant using jpa and can eventually move to toplink. But who uses toplink ?

I'm sorry but I don't understand the question or the answer.

You should ask the question: "Should I code against a standardized interface, using standardized mapping metadata, and a standardized query language, whenever I can?"

The answer to that should be "Yes" in most cases. Now if you made that decision, you pick a provider that implements the standard. Hibernate is a Java Persistence API provider. A good one.

If you ever feel like you need to move outside of the standard API, query language, or mappings, you fall back to a different package or an extension that the provider supports. In Hibernates case, that includes any Hibernate functionality.

This is not an "A versus B" or "one without the other" question.

I have a related question about Hibernate vs JPA. I understand that programming to standards is always preferable, but some people where I work are concerned that JPA is "new", and that we should stay with standard Hibernate (with Hibernate annotations, but without JPA).
My question is: what risks are we introducing if we change from using native Hibernate to JPA? I'm not talking about risks from our application code changes - let's assume that's done correctly and all works fine.
Is the the kind of change that can't go wrong - is there just a trivial JPA facade over Hibernate - or is there the potential for bugs and/or performance changes?

It's just a thin API/mapping metadata wrapper over Hibernate Core.

Christian, thank you for your answers.

I do think that it is better to code to a standard api, this has been th eway to go since j2ee is with us. This way, you can move your application from let's say weblogic to jboss or to websphere. Usually, with minor changes it will work.

When I first tried jpa, I soon ran into a problem, I wanted to use a Money (deriving from BigDecimal) type which is fairly
easy with hibernate but could not do it with jpa. For me, this should have been part of the specification. JPA was not created from scratch like jsf. People had the opportunity to build based on solid frameworks like toplink and hibernate. So didn't they include the best from both ?
I also had two more problems or irritant which I don't remember unfortunately.

If you use code to jpa interface but need to use hibernate's extension, then you are not portable anymore. Why bother learning jpa then because chances are you will have to use extensions ?

To make my point about jsr, I have been through the different jsf frameworks. Chances are that at the present time, you will want
to choose a jsf implementation based on its extensions (file upload is not even in the specification). Some jsf frameworks help build
RIAs some not. You will probably want to use one that helps you build RIAs. And you will find that to produce RIAs, you will have to use extensions too. Then again, no portability.

I of course might be wrong but I think it's no wonder that you find many people flying away from standarzied api from JSRs.

Regards

So you are saying that instead of just coding maybe 10% of your application against proprietary APIs, you would prefer coding 100% against proprietary APIs because nobody needs 90% anyway? Are you sure that this kind of logic works?

Christian, unfortunately I need 99% portability if I am to switch to jpa. JSRs were made so that you can switch from one implementation to the other with not much work bringing a fair competition against different implementation to the benefit of the end developer (but you already know that).

Knowing that there is 10% of the code that needs to be rewritten, I don't know of any project manager that would allow a switch from let's say hibernate to toplink unless there are major problems with new versions of a release. In which case, the projects would simply live with current working version and new projects would start with a new implementation. And even though here we would have a case where developer would have to learn the new implementation, is that ever gonna happen !?

I think jpa has a future but I will be waiting for the next release unfortunately. Just to make sure that things that were in my opinion not delivered and should have (in fact I mean perfectly), will be next time.

I am not blaming anyone for that, I am sure you are all spending an enormous amount of efforts and comments like mine must be frustrating, I apoligize. You write books, take time to respond to us, make hibernate a success, this is more than I will ever do. I really do admire your work, so again don't take my comments as negative critics.

BTW, great book, I will take a few minutes to post a review on Amazon.

You won't ever get that for any specification in the world.

I think you misunderstand the purpose of standardization. The goal is never a 100% guarantee that you can switch one product for another without touching any code. The goal is that you can switch if you have to, and that you can calculate the cost before you make that decision. If that decision is negative for a particular project, so be it.

I currently work on a real project and I use JPA only for half of my data access code, the rest is extremely sophisticated Hibernate stuff. And this is of course all just fine because the next person looking at it won't have any problems understanding the JPA part. Better 50% than nothing. If you really have architects or project managers who think otherwise, fire them before they do more damage.

thanks christian!