Same Engine, Different Body

For various reasons I have been writing software again. It's mostly hobbyist stuff or small, useful applications. My TagCloud software has been incredibly useful and was fun to work with. I used to write and design software for a living and it was not nearly as much fun (that's why it's called work folks!).

So, my latest project is a rewrite of an an old travel planning tool that I built in Access years ago. Keeping with my current fascination with modern web-based development, I decided to implement this application as a Java servlet within a Tomcat container. I've been writing Java code since it was new and like many aspects of the language and virtual machine architecture.

One of the big advantages to OO programming is the ability to hack together pre-written chunks of code to build applications quickly. Java makes it very easy to dump in different frameworks for important functions. Need to interface with a database? JDBC makes this easy. Make mine a web server application please. It's easy with the servlet interface.

This advantage also leads to Java's biggest problem: framework and component proliferation. This is most evident when you are building web interfaces. There are all types of competing frameworks and it's easy to get confused. Should I generate the interface as pure HTML/JavaScript from within the servlet? How about using Ruby on Rails, though that means learning yet another language. JavaServer Pages (JSP) might handle some of the static portions of the interface. Is that enough? Should I use a web UI framework? Okay, which one? Struts or JavaServer Faces (JSF)?

It makes my head hurt.

This is the dark side of component and object technology. The things you need to know become so great that you need armies of specialists to write even a simple application. If you don't think this is out of control consider this: Nine years ago, ever thing I needed to know about Java could be found in the two O'Reilly books "Java in a Nutshell, 2nd Edition" and "Java Examples in a Nutshell". At that time they had 11 books altogether about Java, but many rehashed the same subjects. The "Java in a Nutshell" book was only 610 pages long.

Contrast that with what is available today. They O'Reilly web site lists over 125 books on the subject (I got tired of counting) and the 5th edition of "Java in a Nutshell" is listed as having 1252 pages, more than twice the 2nd edition. In 1997, there was one UI choice, the AWT. Now there is still AWT but also Swing, Spring (whcih includes a bunch of other components), the aforementioned JSP, JSF, and Struts, and the Eclipse SWT. Or maybe I could use Ruby on Rails to generate the interface or even JavaScript on Rails. I don't even want to get into all the other extensions, component libraries and frameworks available (J2EE, JavaBeans, AspectJ, JXTA god know what else).

Now if you think this is simply the ravings of a weekend programmer who can't make a decision, consider the poor system architect who has to design a major enterprise application. Not only do they have to evaluate and choose what parts to use but those choices will drive specific costs. Training, books, and time will cost money. Just keeping up with versions and updates could occupy someone full-time. It's job security I suppose.

To be blunt, this is too much of a good thing. Granted, no one wants to have to write all of these parts from scratch. Talk about serious time issues. However, we could do without so much duplication. Do we need Struts and JSF? I'm sure that someone out there is yelling "Yes! By gum we do." and will have a dozen reasons why. Most of those reasons will turn on some minor technical or philosophical issues that matter to only tho a handful of people. I'm sure that some will also argue that it's about choice and choice is good. Maybe, but it's also confusing.

I don't offer a solution here. This probably won't happen with .Net. Microsoft keeps too tight a control on its technology to have this happen. It might also help if the Java community would line up at least the competing technology and pick just one in each group.

In the meantime, I will, like everyone else, make my choices and hope they are the best ones.