I see that Hibernate home page has a symbol informing that it implements JSR 317, but I couldn't find if it implements the full spec. Does anybody knows if Hibernate 3.5.0-CR-2 fully implements the JSR 317?
I can see from their JIRA that everything is closed related to JPA 2.0:
http://opensource.atlassian.com/projects/hibernate/browse/HHH-4190?subTaskView=all
Anyone has experienced using JPA2.0 with Hibernate? Does it implement the full spec?
The release notes for 3.5-CR1 claim full JPA 2.0 compliance:
I am pleased to announce that we have
just released Hibernate version
3.5.0-CR-1. As a refresher, Hibernate follows the JBoss versioing scheme
where CR is a "Candidate for Release"
(what many of you might call RC).
The main stated goal of 3.5 is JPA 2 compliance. This is the first release
we believe achieves that goal
entirely. In fact we are in the
process of certifying for standalone
JPA 2 compliance and have integrated
this CR into the imminent JBoss AS M2
release as part of their effort
towards full Java EE 6 compliance.
I am afraid to tell you that my own experience with the JPA2 implementation of Hibernate convinced me to wait a little.
For some reason, I could not get some very simple beans persisted, even worse when trying to generate some really basic relations. Replacing the Hibernate implementation with EclipseLink made the same code, which I promise is consistent with the JPA2 reference, work.
I would vote for EclipseLink.
Related
AFAIK, the latest and greatest that I have been using is JPA 2.0.
I am befuddled that GAE has a jar somewhat called appengine-java-sdk-1.6.5/lib/user/orm/geronimo-jpa_3.0_spec-1.1.1.jar. I have been having the impression that GAE always has a latency in adopting compatibility with latest, greatest bleeding edge protocols. It took them some time to adopt JPA 2.0.
What is that JPA 3.0 jar doing inside GAE SDK libs? Is there such a version as JPA 3.0? Is Google one-upping us this time by implementing a new version protocol ahead of everyone else? Is there a JPA 3.0 spec or reference impl somewhere I could refer to?
I am not (currently) an EJB person (sorry ... had decided to avoid EJB ever since I had bad experience with EJB 1.0 10 years ago).
Is EJB 3.0 synonymous with JPA 2.0,
or is JPA 2.0 adopted as a subset of EJB 3.0
or is JPA 3.0 = EJB 3.0?
WRT this question I asked: moving from Hibernate entitymanager 3.6.9 to 4.1.2 crashed mysql connection,
Is Hibernate entity-manager 4.x somehow related to JPA 3.0 or at least a JPA version later than 2.0? I am experiencing significant differences between Hibernate entity-manager 3.x and 4.x (and have so far avoided deploying 4.x).
I realise this question is rather self-confusing and may be I should have asked each of the items as individual question, but I am hoping some one could tie all these together in a single thesis: ejb 3, JPA 2/3, geronimo, hibernate ent-mgr 3/4. Thanks.
No there is not such a thing (in June 2012) as JPA3. There is JPA1, JPA2, and (in planning) JPA2.1. That geronimo-specs jar is actually for JPA1 but some very shortsighted person/group decided to name it like that, and are now seeing the consequences of it.
As you say GAE already does support JPA2, using v2.x of their JPA plugin as available from Maven repositories or here http://code.google.com/p/datanucleus-appengine/ and that works with a compatible jpa-api v2 jar (such as geronimo-jpa_2.0_spec).
As others have said, JPA 2.0 is the current version (part of Java EE 6) and the next version is going to be JPA 2.1 which is currently in specification (JSR 338) and going to be included in Java EE 7. There is no JPA 3 as of yet, so that JAR is just badly named.
JPA 1.0 was introduced as part of Java EE 5, splitting the persistence part from the EJB specification (so Java EE 5 introduced EJB 3.0 and JPA 1.0, no more Entity Beans, yeah!). Java EE 6 then included EJB 3.1 and JPA 2.0.
Java EE 7 will include EJB 3.2 and JPA 2.1.
I am speaking under correction here as things might have changed since I last seriously worked with JPA. However JPA 2 from my understanding is the current specification. I doubt the jar you mentioned is a JPA 2 specification. In 2011 Geronimo did not support JPA 2 out of the box at that point.
As far as EJB's and JPA is concerned:
Both EJB and JPA are based on POJO's (Plain Old Java Objects).
JPA classes is essentially a data access layer technology i.e. used to interact with your data layer.
EJB is essentially used for a business layer. It would contain business logic and orchestrate interaction between different JPA classes. For example in JPA you might have a Customer Class (which interacts with the Customer Table) and a Orders Class (which interacts with the Orders table). In your EJB you will use both these classes to create a new order for a particular customer.
When using JPA as a technology it allows you to keep your database access funtionallity in one layer. This layer could be used by EJB's, a web application(Servlets,JSP,JSF), web services and even a swing application. This will keep the database access logic consistent across all these applications. Changes to the database will then require a change to the JPA.
This is a very simplified explanation of the differences and this subject matter is really deep but these points should help you differentiate between the two.
By the way the new EJB specification really makes beans very easy to use, develop and deploy. I am lucky I missed the original specification all those years ago. Currently they are very easy to use.
Hope this helps clear up the mist a bit.
I'm wanting using JPA in ear project. Development project must be started ASAP so I have not a lot of time to research and investigate. Could you say please JPA API is restricted functionality of Hibernate or no. At this moment I'm using Hibernate directly. For example in future I'm planing to use hibernate-search and maybe hibernare-validate and -shard. Can I be sure that in future I will not have problem with using this.
And one more example - can I use HAR archive and JPA together.
Why JPA? For project will available RESTful service (jersey or resteassy implementation). And as I looked in much case using JPA for this. I'm a newbie in this so it's only my IMHO. May be i mistakes.
Thanks a lot.
Best regards
Artem
JPA is a subset of hibernate, but you're not limited to it. If you need a hibernate specific feature, you can generally use it at the cost of being tied to hibernate. For example, we've mixed in hibernate annotations with JPA ones, including the validater ones, without trouble.
JPA in theory lets you change the persistance provider later.
Sticking to only JPA compatible configuration can cause more trouble that is solved by the dubious promise of seamlessly swapping providers however.
This morning I was aboard a S-Bahn (German Subway) and I met a fellow student, who works for IBM. What he is doing there is Java EE optimization. I told him about my little project. And he recommended not to use 'oldschool' Hibernate. That's why my question is:
Is Hibernate deprecated?
(In combination with Java EE/Web Development)
..or did he just prate..
No, Hibernate is not deprecated.
However, there's now JPA (Java Persistence API), which is a standard API for doing the things that Hibernate does.
Note that JPA is just an interface specification. You'll need something that implements JPA, and Hibernate is one of the implementations of JPA. Besides Hibernate, there are a few others such as EclipseLink (the official reference implementation for JPA) and Apache OpenJPA.
Hibernate, apart from being an implementation of JPA, does provide a lot of extra advanced feature that JPA lacks of (extra syntax in query, QBC support etc). Some of them are really useful and hard to find a workaround in JPA world (yet). Without providing such features, it is hard to say JPA can "replace" Hibernate (hence, saying Hibernate being deprecating)
Hibernate is the JPA provider offered by JBoss, which is a Java EE server, so I doubt that Hibernate as an implementation is deprecated.
Perhaps he meant that using Hibernate within a Java EE server , bypassing the container-provider persistence, is deprecated and you should rely on our container for such services.
No, there is no way that Hibernate is deprecated. There is the JPA which is a persistence specification and Hibernate implements it. Also Hibernate has its own advanced features that JPA does not have and that's why Hibernate is the main source of new features that are added to the JPA standard.
One possible reason why he may have suggested you against Hibernate is that for a small project, the overhead of understanding Hibernate can be quite significant.
Hibernate is vast to say the least. Though it can be used in a simple way, but to find that out too, you'll need to comprehend a whole lot more.
but be rest assured that Hibernate is NOT deprecated, or going to be any time in the distant future. it's just that if your ORM needs are modest, you might want to try other solutions like iBATIS
JPA is only one way to do it. There's still Spring and all the other frameworks where Hibernate is well alive.
Based on what you said, it sounds like he may have been referring to Hibernate xml mappings, in contrast to using Hibernate annotations or JPA. XML is most certainly old-school rubbish.
When is better to use Hibernate and when EJB 3? Aren't there any impediments with either Hibernate or EJB 3?
I'm in the direct hibernate camp here.
Just think how likely it is that your going to what to change your database say from DB2 to oracle, well that is about as likely as changing from Hibernate to Toplink or eclipse it just isn't going happen that often. It's the same old thing that programmers just love to do and that is abstract any stuff so that they can in at some unforeseen point 10 years from now choose to use a different logging tool kit or what not.
There are I'm sure people out there that really want the vendor independence of JPA but I'm not one of them. That's not to say that Toplink or eclipse aren't any good, I just don't think you can use a product that complex and not be tied (even unintentionally) to it in some way.
Having said that I still follow the hibernate documentation advice and use the JPA annotations and only resort to the hibernate specific ones when I need to, not quite sure if there is a technical reason for this, but it doesn't hurt.
Since Hibernate can be used as an implementation for JPA, you can use it and still be using EJB3. As such, I agree with gid and suggest that you use the JPA stuff in Hibernate until you can't and only then move to Hibernate specific bits.
I'm researching the development of Enterprise Applications in Java, .NET and Groovy. For each platform, we're going to try how hard it is to realize a simple SOAP web service. We'll use the tools and libraries that are most commonly used, to research the real world as accurately as possible.
In this regard, when using Hibernate for persistence, would it better reflect the real world to use the new JPA (Java Persistence API), or the Hibernate custom API that existed before JPA came around?
As you're probably already aware, as of 3.2 Hibernate is JPA certified. You can easily use Hibernate as your JPA provider without having to use any of Hibernate's "custom" APIs.
I'd recommend using straight JPA with Hibernate as the provider. And use annotations rather than XML (much nicer).
Then when you need a little something extra you can always get the Hibernate Session. For example I often find I need to do this in order to pass a collection to a query as a parameter (setParameterList).
It's funny how you worded your question
new JPA ... or plain old Hibernate
Sounds like one has been around forever and the other has just been released. Of course it's not true. JPA was influenced not just by Hibernate but also by TopLink and by J2EE entity beans. The first reference to JSR 220 draft is back from 2003 - how is that for new?
If you use JPA with Hibernate you still use Hibernate and is free to apply any proprietary extensions Hibernate has.
So the choice is yours: use proprietary API or use equivalent established and standard API...
You could stick with a pure JPA spec, just in case you want to swap out Hibernate, but what you'll probably find at some point is that you're never going to swap it out, and you've been missing out on all the really great Hibernate-specific features.
I'd recommend using Hibernate directly, and as Damo suggests, annotations instead of XML. Make sure you have a firm understanding of the "magic" that Hibernate brings. If you're not careful, you could really thrash the database. For example, there's an n+1 query problem depending on how you do #OneToOne joins:
Hibernate OneToOne automatic join fetching (resolving n+1 problem)
I'd also recommend to use an embedded database for unit/integration tests on your Hibernate queries, and watch the SQL that's generated to make sure it looks like something you'd write by hand.