The 3rd Dimension of Java Freedom
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
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.
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.