CODEWITHSUNDEEP
hibernatejpa-2.0
Benjamim
Benjamim

Reputation: 108

Jpa vs Hibernate - Standard or functionality?

We are starting a project and our architet wants to use everything on standards (Calendar instead of JodaTime - JPA2 vs Hibernate 4). And i was using JPA2 and I realize that so many functionality was lost in the pretext of "standards" and portability.

So I ask this question: Is it worth to lose some functionalities because of standards and why?

Is that commom to change ORM to think about portability?

They have a project that have 7 years old and still use OJB as their ORM...... can you give me an enlightment about this?

Thanks.

Upvotes: 3

Views: 1188

Answers (5)

rai.skumar
rai.skumar

Reputation: 10677

Quick one liners:

JPA - Java specification (part of Java EE) for persisting/accessing/updating objects(known as Entity in JPA) to databases.

Hibernate - JPA provider (i.e. one of the open source JPA specification implementation). Also please note that you can use Hibernate without using JPA as well.

Have more details on my blog, here.

Upvotes: 0

Ravi
Ravi

Reputation: 1

Hibernate has additional features like Hibernate-Search and Envers.

Upvotes: -2

meriton
meriton

Reputation: 70564

Standard solutions have the advantage that everyone is using them. This means:

  1. It will be easier to hire people familiar with the technology, and easier to train people
  2. It is less likely the library will be abandoned, or become otherwise unfit for use (for instance due to exorbitant licence fees the provider can get away with due to vendor-lock-in) - and even if it does, some other user of the library might have pioneered a migration path
  3. It is easier to switch to a different implementation of the standard should the need arise (and who can be certain the need will not arise in the presumably many years the software will be maintained?)

For example, what if Red Hat fell on hard times, and stops making new versions of hibernate freely available, but now asks for a licence fee? Or what if the makers of Joda time discontinue development?

Therefore it makes sense to use standards where they exist. It can also make sense to sacrifice some ease of development to limit dependencies - how much of a sacrifice is worth it is a judgement call (it is certainly possible to drag libraries into the classpath for no real benefit. The other extreme is reinventing the wheel, simply because the wheel has not yet been standardized.)

They have a project that have 7 years old and still use OJB as their ORM...... can you give me an enlightment about this?

Probably because the code talked to OJB using an API for which there is no modern implementation, making it very (prohibitively?) expensive to switch the provider. Perhaps that is the very situation your architect is trying to prevent by restricting you to standard apis.

Upvotes: 1

Daniel Alexiuc
Daniel Alexiuc

Reputation: 13240

Settling on JPA is probably a good idea - it will cover most things you need. I wouldn't make the decision based on how easy it makes it to switch ORM's though - it will likely never happen and even if it did, there would be plenty of other things to worry about first.

If you are using Hibernate as your JPA provider, you can always fall back to Hibernate specific functionality in the places you need it.

Upvotes: 0

Cengiz
Cengiz

Reputation: 4867

For my experience use Hibernate 4. You will never change your ORM framework within an application. The standards have very long release cycles comparing to non standards. This makes it difficult to get new features or bugfixes. Further i would say that Hibernate is a quasi standard. Hibernate offers much more features than JPA. I would not abondon them.

Upvotes: 2

Related Questions