Question

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.

Answer 1

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.