It’s widely accepted that it’s a good idea to use standards in software applications. But is this really true?
Let’s take JPA (1.0) vs Hibernate as an example. A lot of people use Hibernate as JPA implementation in their project. The idea is that one can easily switch to another ORM framework that implements JPA.
That sounds as a very good pro but what is the chance that within that specific project another implementation than Hibernate will be used? Why would you want to change?
Standards are made to introduce a general way of working. If you know JPA you don’t have to learn specific implementations like Hibernate, iBATIS or TopLink . That’s true. But what if the standard doesn’t support everything that a specific implementation can do? Will you still use the standard even if you lose some features? In my opinion the answer to that question is definitely ‘no’!
Did you ever try to make use of delete-orphan with JPA? You just can’t do that for the simple reason that it’s not supported by JPA. Solution: use the Hibernate implementation instead.
Another example: Criteria API. You can use Hibernate’s Criteria API for retrieving entities from the DB. It’s not included in JPA. Same for Hibernate Validator. It’s not (yet) included in JPA. So we still use Hibernate specific code.
I know it’s included in JPA 2 but to be honest, how long will it take till a lot of projects will use JPA 2? It can take some time until a new version of some framework will be adopted by a lot of people. The point is that standards seem like a good idea but most of the time not enough features are available at the time the first stable version is released. They’re immature at the moment a lot of people start using them. Which means that the introduction of a lot of standards comes too late.
In my opinion standards can be useful in a long-term project subject to a lot of change like a framework or something similar. But in most of the fixed price software projects an immature standard can be contraproductive instead of generating a lot of added value.
about:software development 
Comments on: "Standards: Pros and cons" (7)
I agree that for fixed price projects, not following JPA will get you towards the end sooner.
But the choice is not an easy to make. Take the following scenario. Nobody knows if your ORM solution will be around in 5 years. Or that it is still actively developed. If there is any certainty in software development, then it is that applications will evolve. 5 years is nothing for an application that has cost a lot of money. In the case that your specific ORM impl ceases to exist in 5 years, then you’re basically screwed when the customers asks you for something that’s really easy to do in let’s say JPA3, but your ORM solution didn’t implement. And then you’re stuck with an ORM solution from 2010, a typical vendor lock-in case.
So it works both ways. I agree with your statements, from a developers perspective I would pick Hibernate too for fast development. However, if I were a customer … I would ask to use JPA 😉
Hibernate validation 4 implements the JSR 303 bean validation API.
According to this post it is included in JPA2:
http://relation.to/Bloggers/BeanValidationJSR303HitsProposedFinalDraft
IMO there is also a big difference in rolling your own classes and frameworks because a certain standard does not meet your requirement and sidestepping to hibernate specific code for certain functionality (hibernate is a de-facto standard for ORMs) whereas your own code would probably be far less advanced than hibernate. Beware of the “not invented here syndrome”.
Standards reduce the risk that what I learned, what I spent time on, is worthless in the next project or with the next release of a product.
The use of a standard means other developers can easily integrate in a team and quickly get a hang of the projects structure – without struggling with subtle semantic differences between products.
An end project does not need to be agnostic to the used fundamentals. Changing the JPA provider is highly unlikely. Easily switching the JPA provider is *not* the idea. (In contrast a library has to be agnostic to be widely useful.) So you typically would built the basics using the standards and use the provider specifics where needed. You can get the Hibernate session from the Entity Manager and use the criteria api with it. You can use Hibernate cascade annotations when using JPA and Hibernate as provider. Best of both worlds.
Really, really bad examples, since JPA2 includes both orphan deletion and a criteria API that is waaay cooler than the criteria API that Hibernate had for a long time:
http://in.relation.to/Bloggers/ATypesafeCriteriaQueryAPIForJPA
Meanwhile, Hibernate Validator is the inspiration behind the new Bean Validation spec. But, of course, the new Bean Validation stuff is a massive improvement.
And since these JPA2 features are *already* included in the latest release of Hibernate, and Hibernate Validator has evolved into the RI for Bean Validation, I don’t understand why anyone would have to wait to use them. You can start using them now.
Finally, like I keep saying: portability doesn’t have to be “100% perfect world zero-changes-to-my-application platonic ideal portability” to be useful.
http://relation.to/Bloggers/YouShouldUpgradeToJavaEE6
Everyone who developed their projects using JPA1, with bits of Hibernate-specific code sprinkled in, will find migration to the new world of JPA2 and Bean Validation easy. Those who resisted adopting JPA1, despite the advice of the Hibernate team, will find it more difficult.
I agree with some of the remarks about why using JPA is a good idea. Because of the fast evolution in the IT world some risks are introduced -related to code changes in frameworks or semantic differences between the different implementations- and you can minimize them by using standards. But if you look at a project-by-project-basis, I don’t see that many risks related to this problem.
Development of most projects I’ve participated in takes 6 months to 1 year and in that period it’s unlikely that you will choose another ORM tool for example.
Of course standards will evolve too, in most cases it will pick up features from the de-facto standard (cfr JPA and Hibernate). It’s a good idea to use the standard when it contains all (or most) features you want but I wouldn’t force the usage if it’s not the case. JPA2 will be great but IMO JPA1 has a lot of missing stuff. You can use some parts from Hibernate together with JPA1 (criteria, cascading, …) but you’ll still have to know what Hibernate can do + how to do it with Hibernate.
The use of standards can make integration of other developers into a project faster, that’s true, but what I see as a big disadvantage is the amount of complexity it can introduce. I know this sounds contradictory, but take a look at another example: logging. In the beginning a lot of people used LOG4J and it did what it had to do. Later on logging was introduced into the Java API (Java Logging API). There’s also Apache Commons Logging and now you have some kind of standard/facade: SLF4J.
I don’t deny that the existence of SLF4J is good, because there are so many logging frameworks and you want to be able to use another one without knowing them all by heart. But if for every kind of framework/dependency, you must add a dependency to the standard and its implementation you are using, you’re not only having a lot of dependencies, you’re also creating an extra level of complexity so setup will be more complex.
An so called advantage that I hear very often is that a standard hides you from the concrete implementation (=underlying framework). But IMO that’s not completely correct. Leaky abstractions (http://en.wikipedia.org/wiki/Leaky_abstraction) can never be avoided. As I mentioned before, you will always have to know at least something about the underlying implementation.
My personal conclusion: the use of standards has some pros but there are definitely a lot of cons too and that’s something you should be aware of too.
[…] Standards: Pros and cons February 2010 5 comments […]
After I initially commented I appear to have clicked on
the -Notify me when new comments are added- checkbox and now whenever
a comment is added I receive four emails with the same comment.
Perhaps there is an easy method you are able to remove me from that service?
Cheers!