I will let Emmanuel answer this one. He is the JPA spec lead after all. I will tell you that as I am a heavy user there are quite a few differences. Probably too numerous to mention here but he can give you the main ones.
Be patient, he is in Europe at the Devoxx conference this week.
P.S. I highly recommend 'Java Persistence with Hibernate'. It is not for the beginner but it discusses the differences quite well.
Until you get the answer from Emmanuel I'll jump in here ... the replies you've gotten so far haven't really told you much.
JPA is essentially a wrapper around Hibernate (and TopLink, OpenJPA, etc). Meaning that it is a set of standardized APIs that use a defined peristence provider. It is much like JMS being able to communicate to various message providers or JDBC communicating with different databases.
The advantage of JPA is that, even tho it is part of the EJB 3.0 spec, it does not require a container to run ... you can use it in non-EJB apps. JPA provides a consistent interface to different ORM persistece providers, so, in theory, you should be able to change out the provider, say from TopLink to Hibernate, with no code changes other than the persistence.xml file (the JPA configuration file).
The downside is that, since it is meant to provide a consisent API across different providers, unique features of individual providers are not supported. For instance, Hibernate's criteria API is not supported in JPA. If you want to use it, you can even while using JPA, the problem is that you are no longer provider neutral and should you want to change providers you will have to change code ... or you can use some 3rd party criteria implementation that promises to work across providers (like Rich Hightower's Krank project -- specificially his GenericDAO stuff ... there are others too).
Anyway, just a quick overview comparison -- they're meant to be mutually inclusive rather than exclusive.
Just a clarification, I am a member of the JPA expert group but I am not the spec lead
JPA is the specification that provides a standard way to define mapping and a standard API to sue an ORM. The features and API are very similar to Hibernate. Of course it's a specification so some features will not be standardized. That's OK, you can use the JPA APIs and mappings annotations and fall abck to the Hibernate APIs and mappings if you need to. They are more complementary than opposed.
If you ahve an existing application using Hibenate, there is probably not much interest in migrating, that's an architect / financial choice.
"How many licks ..." - I think all of this dog's research starts with these words. Tasty tiny ad:
Free, earth friendly heat - from the CodeRanch trailboss