The Joy of Setting Up a Java Framework

by Krishna on December 2, 2007

Joy? Actually, no. Unfortunately, Java is becoming a victim of too much innovation. Anyone doing web development using a Java-based framework is faced with an abundance of choices and very little guidance and help from the innovators. Here, take a look at these lists: Apache projects, web frameworks, persistence solutions, web servers, IDEs, etc. What tools and projects would you choose for your next development?

Here are the challenges:

  1. Many projects have no published timelines for compliance with the latest standards or emerging technologies.
  2. They rely on external solutions to provide key functionality such as object-relational mapping.
  3. They have a very cumbersome installation process that involves tinkering with a multitude of XML files.
  4. Documentation is non-existing, elementary or plain wrong. For some reason, the developers are interested in only writing books, not free online documentation.
  5. If you are interested in going bald, try combining multiple components to accomplish something useful.

How would you feel (or rather, experience) if you were given the following steps for disposing a bomb over the phone?

First, cut the green wire.
Now, cut the blue wire.
Sorry, before cutting the blue wire, you should cut the red wire.

That is how installation works. When you follow all the steps and try to run your application, you encounter an error. You spend a tremendous amount of time walking through and verifying all the steps again. It doesn’t work. Then you read the next chapter and it says, “Hey, by the way, you should also do this.” Wonderful, thank you.

A few years back, I remember seeing a website that had a single installation that bundled all the popular Java and open source products and promised to get it all working. I couldn’t find that site, but I think that is a business idea that must be revived with respect to a Java framework. Here is what I think it should look like:

  1. It goes without saying that all the components should be open source. But there are various types of open source licenses. Hence you may have multiple versions: “Free for any commercial use without restriction”, “Free as long as you give away the source code”, etc. Yes, that means not forcing people to figure out the difference between GPL, LGPL, Apache and BSD licenses.
  2. Again, obviously, there must be different installations for different operating systems. My point in stating this is that each operating system has its own preferred way of installation. If it is a Windows operating system, provide an installer, not a ZIP file.
  3. Any installation configuration must be done through a visual interface both at and after installation. The user should not even know how that information is stored.
  4. The installation must package a visual IDE. Otherwise it is just a development kit. Eclipse is a popular choice.
  5. The installation must package a lightweight J2EE server. When you create a new web application, it will run in that server when you press the Run button. No questions asked.
  6. The installation must bundle the latest database drivers for different databases.
  7. It must contain searchable user-friendly help and meaningful tutorials that are available locally. It should ideally have the ability to download and index new articles from selected web sites.
  8. And the killer feature: It will offer its own choice of frameworks by combining the more popular frameworks to provide end-to-end functionality.

Let me explain the last point with an example. For example, Struts is an MVC framework. You could have a more powerful framework by adding a Java persistence component. So an installation process could let you choose “MVC — yes or no?”, and “JPA — yes or no?”. As you choose each one, it could offer you choices of the most popular solutions available.

When any of the underlying components change, a patch build should be available to download and install silently. The vendor should do the hard work of making sure that the new version of the component does not affect backward compatibility.

Doing something of this sort is pretty expensive, but not impossible. It would be similar in scope to creating a Linux distribution and certifying it with various hardware devices. Someone interested in pursuing this business idea has to hire testers, technical writers, and usability experts, in addition to developers familiar with different operating systems and environments.

What I have outlined is simply applying the Visual Studio concept to Java. Unfortunately, the companies that have the resources to do this, like IBM or Oracle, are intent on plugging their own Java solutions in the server and IDE space. Maybe someone else will come along. Till then, less joy and more pain.

Comments on this entry are closed.

Previous post:

Next post: