The trouble with standards — when less is more

Lately I have grown somewhat disillusioned with all the standards we have in Java. I find myself wondering whether the single middleware vendor model, as with Microsoft and .NET, might be better. I have nothing against standards. In fact, I like them. But they come with pitfalls we should consider.

If a standard is imprecise, uses wording open to interpretation or leaves room for extensions, you can bet each implementer will read it their own way. A classic example is the application server-specific deployment descriptors for enterprise applications.

Standards always trail the times. Specifying one takes a while. If that takes too long, its value declines as development moves on. We have the Java Persistence API specification, and it is certainly encouraging that it drew on Hibernate, a successful vendor-specific solution. But Hibernate is already two steps ahead.

Broadly, I would say an environment with no single dominant middleware vendor favors vendor-specific solutions. I would not take this as dogma, but the different areas of J2EE each have nuances to look out for. An example?

Suppose you want ORM and can choose between JPA and Hibernate. Your heart says to use the standard, JPA. Portability between application servers is a huge advantage. But experience says some problem will always crop up that sends theoretical portability to the grave. With Hibernate, I can also already use features that JPA does not cover and that happen to suit me very well.

So any evolution in JPA would come through the implementation-specific extensions. Use one of those and you are in the same position as if you had chosen Hibernate at the outset, dependent on a particular implementation.

I like standards, but sometimes it is better to weigh the pros and cons before following them blindly…