Portable runtimes with defacto standards or standard APIs?

My Spring blog post had an (anonymous unfortunately) response which I responded. But, it prompted some thinking thats turning in to a rant so here it is.

Whats better? A single portable implementation of a defacto standard or an official standard or a dozen different proprietary implementations of a standard API. First, it depends on what kind of function the API is for but for some types of API, I'd argue for the former.

Lets take the topic du jour (at least in my head :) ), Spring versus EJB 3.0 based injection.

There are a lot of advantages to a runtime that is portable when compared with different implementations with standard APIs. Same implementation means consistency because no matter how good a TCK (compatibility test kit) is, there are always implementation differences and this limits portability even with a standard, we all have experience in this area so this shouldn't be news to anyone. But, take Spring Vx.y and move it from Tomcat to WebSphere, and it works exactly the same because it is the same. Sometimes, a common implementation rather than a standard API is what you want.

Plus, when they release the next version of Spring, you know, the one that replaces the kitchen sink AND does injection, you can just use it on your existing older runtime by simply swapping jars. Hands up who thinks when the next EJB 4.0 injection upgrade comes, it'll be that easy or hands up who thinks you'll need a full server upgrade to get it. No prizes here because it's a rhetorical question. How much money will that cost customers? Think about it, it's a lot of money. I wish I had 0.1% of that number.

And further, someone should calculate how many times EJB 3.0 injection is being developed right now around the world. What's the cost to the industry in terms of person years? How much value to customers is having a dozen implementations of the same simple standard API versus if the same man power went to innovating and developing an improved injection runtime. It's just nuts. There are only so many ways to inject a value into an attribute and at the end of the day, how much better is one implementation really going to be versus another. Very limited benefit to customers resulting from this competition in this case.

In my opinion, we would have been better off adding a generic injection capability to the J2SE platform (so to avoid this global reinvention of a simple injection spec) and then leveraging it in the EJB 3.0 spec and then revving it as an independant component usable with Java 5 or higher rather than coupling it to a J2SE level. As the injection component gets better, the JavaEE spec gets better indirectly but why couple them? That just slows innovation down by extending release schedules and having interlock meetings :) Interface 21 could have owned (I don't know if they actually would have, this is conjecture) and developed this independantly of Sun. What difference would this have made to customers? I'd argue customers would have been better off. Then, instead of developing a dozen implementations on this API, that man power at J2EE vendors around the world could actually have been doing something interesting that actually benefits customers rather than reinventing the wheel as well a round(er) wheel.

Now, this doesn't apply to any kind of APIs. For some stuff, implementation competition is a good thing and customers benefit in terms of faster implementations etc but I don't think this is true of something like EJB 3.0 injection. This is a much more limited gain in terms of the customer benefit versus the costs to the middleware industry of this reimplementation.

Comments

Bill Gates couldn't have said it better.

[Billy]

Ouch
Well, that not what I'm suggesting. Bill gate would have that approach, and indeed has that approach, with ALL APIs.

That isn't what I'm suggesting. I'm saying there are two types of API. One set with low value where competition doesn't buy much so have a single implementation. The other set has high value and competition is a good thing and the customer benefits.

The J2SE is an example of that. There is no value in having a 100 BigDecimal classes or java.concurrent implementations. So, do one and put it in the J2SE level. I'm just saying that the JavaEE spec has quite a few examples of low value APIs, boiler plate implementations.