The 3rd Dimension of Java Freedom

The Introduction

Our grand project at ASIX, Inc was to both build a business framework in Java and a business application on top of it. Tragically, the contract for the application fell through and ASIX is left with a framework. The framework was designed to simplify the building of standard business applications. ASIX is wondering if there is a market or interest in the industry for this type of framework. This situation has prompted me to discuss the desire for freedom that led me to Java five years ago when I started building this framework.

Why write another framework when so many others are available? Actually, there has been very little effort in the Java industry aimed at building tools that focus on business application developers. Some companies have started exploring this area, but their solutions tend to tie the developer to a particular server vendor. If vendor independence is a nice to have, but not a deal breaker, then what about technology independence?

The Why

What if there was a tool that allowed technology choices to be deployment and not development decisions? What if during the development process the whole application could run in one JVM to maximize developer productivity, while for production the application could run on several machines in a distributed multi-user environment with no code changes? For a project with a lifespan of more than six months it is best to keep the technology decisions open and be able to choose the best solution today and a different best solution tomorrow.

Commonly, all of the core technology decisions are made before a project starts and it is unlikely that any flaws in those decisions will be corrected as the correction may force development to be started over from scratch. The common wisdom is that, if you initially choose wrong you loose.

What we want is to be able to initially decide to use EJB’s on the backend and then latter change to plain old Java objects and an object relational mapper and not be forced to do a complete rewrite of all of the working code. Additionally, we want to make similar decisions about the presentation tier where we may start by using Servlets and then realize we should use Swing and then decide to switch to SWT or decide to use Servlets for some users and Swing for others. While moving between vastly different technologies will always have a cost, but we should not loose all of our working code. The application that is being written did not change so why should the code?

There is also a developer cost to switching technologies where, currently, developers must be experts with the selected technology and generally have little knowledge of other options. So what happens to the Servlet expert during the move to Swing? Would it not be better to hide or abstract away as many details of the technology as possible so that there is not a huge mental or human resource transition as the project morphs to use the latest and greatest technology?

Likely you are saying, “Impossible, neither goal is achievable!”. Of course you are right. One can not change technologies and not change code and developers will be forced to learn something about the new technologies being used, but do we need to rewrite the application? Do the web developers have to become Swing experts? We must remove these hurdles that keep us using outdated and ill-chosen technologies out of fear of loosing all of our working code. We are stuck with choosing and sticking with common and recommended technologies that have the most support and largest developer base. While we might feel safe, we have also locked ourselves in a prison of status quo.

The 3rd Dimension of Java Freedom

Java is all about freedom. The JVM gives us freedom from being stuck on a particular operating system or a hardware platform. The JCP gives us freedom from being tied to a particular vendor by allowing many implementation choices certified for each approved specification. What most developers miss is that the Java language is capable of giving us the long-term freedom to move from one specification to another or to support several alternatives simultaneously with minimal effort.

So far this last freedom has been left up to the developer. Some general guidance is given in the form of design guidelines or patterns, but no one has provided a generic solution or clearly stated the problem. One goal of development is to be able to absorb a single change in the environment by changing the code in a single place. Patterns like MVC, methods like Refactoring, practices like Remove All Duplicate Code, goals like separation of concerns and decoupling and language features like object orientation and constrained visibility are all trying to help lessen the code impact of an external change.

Why do we give up our principals by tying ourselves to particular technologies? Some say the definition of a legacy system is one that is in production, but this does not need to be the case. Our software systems can remain flexible and adapt to changes in technology and will never need to be retired or rewritten or replaced, as long as, Java remains the foundation. Sometimes a quick and dirty disposable solution is the right choice, but for larger more long-lived systems, it is worth the effort to remain technology independent.

Where is the application anyway? Is it hardcoded into the EJB or Servlet thereby making change costly? It is this improper and unnecessary coupling of applications and technology that I am trying to highlight as a problem. The solution is to put both backend and UI logic, the business of the application, in a place where it is portable across technologies. Not just a rules engine or code generator, but a set frameworks and tools that provide technology abstractions.

The Question

So I ask again, would you be interested in a Java Business Framework that allowed you to safely change your mind at any time, even after deployment, on what technologies you want to use for your application? Even if you do not want a framework, I urge you to not abandon your principals by tying your code to current technologies. Find a way to stay free and make use of the full benefits of the Java platform.

In the next blog I will describe how the Java Business Framework provides technology independence.