musings on java and object oriented software development

Friday, May 26, 2006

Choice is not the problem with Java

Much has been said recently in the Java world about the problems with Java, particularly the problem with choice.

In Java Succumbing to .NET in my Organization
Neil Chaudhuri says that there are two many frameworks, too many IDEs, too many app servers etc. and that is why his organization is moving to .NET. According to Neil choice is a bad thing.

His answer, at least to the IDE "problem", is more standardization, but I believe the source of the standard must come from something that already works, a de-facto standard not a committee standard.

The problem with Java is not choice, but rather that the early standards were created by committee and Sun's "Not invented here" mentality.

Take, for example, EJB.

EJB 1.0/.1 was a fairly pitiful effort. Just horrid, like they gave the job of designing it to an intern. All sorts of (anti-)patterns were born out of 1.1.

EJB 2.0 is a classic example of something born from committee. It mostly did what you wanted to do, but the extra 10% was hard and messy. It promised so much, yet did not deliver and people turned to alternate persistence mechanisms such as Hibernate.

Now with EJB 3.0, Sun has done the right thing; taken something (Hibernate) that works, that people like and makes them productive and turned it into a standard. Yet, they still try to re-invent the wheel with respect to Dependency Injection.

Another example of this is JSF. They formed a committee to define a new web framework, cocked it up and now are already up to 1.2 of the specification. (It probably didn't help that they had the creator of the worst web framework of all, Struts, on the committee).
Why couldn't they have taken something like Tapestry and made it a standard ?

The underlying problem is that Sun have had a real "Not invented here" mentality. They realised a while ago that they couldn't implement anything that was usable (e.g. AWT, then early Swing) so that they started going specification mad. Yet they failed to realise that writing specifications is really hard, harder in fact than writing an implementation.

What should they have been doing all along ? Adopting open-source projects that are de-facto standards and making them into official standards.



Post a Comment

<< Home