[Image] EchoPoint
Helping you build truly dynamic and stateful web applications!

Why would you build your web applications in Java and Echo?

By Brad Baker
Tuesday, September 17, 2002

This article asks the question : "Why would you build your web applications in Java and Echo?". 

After all its got a steep learning curve if you have never used it,  it requires compilation and a set of tools that may or may not be that cheap.  Using Java and the Echo Web framework will require you to invest time into learning its class structure as well as working out its idiosyncrasies.  Why would you bother with so many alternatives?

There are a lot of technologies out there that you can use to build web applications.  With many of them you can get up and going in 10 minutes, with a couple of web pages out the door in no time flat. 

Specifically I am thinking of web technologies such as Microsoft ASP, PHP, and Perl, each with thousands of sites that would indicate that they work.  Can you do that with a Java program?   Why should you even consider using Java and Echo?

Reason 1 - Safety

Well, in my opinion, one major reason you should build your web applications in Java is safety. 

Most of the very popular web technologies are based on scripting languages.  No compiler needed, just type in the source, place it on the server and away you go.  I even class Java Server Pages (JSP) as a scripted environment for the same reason (later versions of JSP servers are providing alternative scripting languages as well).

This means you get going very fast when building your web application.  However this quick startup time is, in my opinion, the downfall of web scripting technologies.  They have sacrificed safety facilities in their implementation for speed of development. 

And this sacrifice has a price :  web application quality.

The speed of development in scripting technologies is a false economy.  Any time you save during the early application development, can be easily spent later in production debugging, trying to determine what is going wrong in the application. 

Some estimates put the cost of finding a bug in the late stage of application development at three times the cost of finding it during early development.  Others put the cost as even higher.

Using Java as your development environment gives you more "development" safety features, that may help protect you from future costly bugs. 

Java has within it (along with a number of other 3GL languages) a set of features that have evolved over the last 40 years of collective software knowledge.  Features such as type safeness, units of compilation, combined data and algorithms (i.e. objects) and  byte code validation can all help you to catch bugs early on.  These sort of features are sorely lacking in the web scripting technologies.

While your testing may not take you down every code path within the application, you can be sure that all code paths do in fact compile correctly.  You cannot go down a code path and have the applications blow up because of a typing mistake or non existent variable, like you can with scripting technologies.

With these features, safe code can lead to better quality applications.

Reason 2 - The Problem Domain

Another major reason to use Java is to keep as much of web application in the one problem domain as possible. 

While scripting technologies are easy to use to develop the presentation layers of the web application, they are not usually used to develop the core "application" functions.  One often has to resort to something like C++ / ActiveX / Perl C extensions (or in the case of JSP, Java classes) to write the deeper functionality.

This means that you have developers swapping mind space all the time between the technologies.  This makes it very easy to make simple mistakes.

Also tools such as debuggers are rarely able to cross the domain from scripting language to 3GL language environments.  This makes debugging all layers of the web application extremely difficult.

Using a Java approach means that you will be hosting the web application in a Java application server.  While different standards are used for the different parts of the application functionality (EJB, JDBC, Servlets, JavaBeans) they are all Java.  Debugging within each share many of the same properties and hence make it problem solving easier.

Debuggers can almost always step right into the depths of the application layers to allow you to determine what is going on.

If you get a completely unexpected problem in the web application, Java's exception handling facilities will allow you to know where in the call stack this occurred and this provides invaluable clues on what might have gone wrong.  It also gives allows you to code your own exception handling code to better diagnose major errors should they occur.

When you are using Java in a Java Application Server environment, you are that much closer to the metal, and that gives you significant advantages.

Reason 3 - State Management

Java, in conjunction with the Echo Web Framework, gives you incredible advances in web state management.

One of the typical problems in scripting technologies is matching "parameters" on the web page with parameters expected at the server.  Name one of these with the wrong name and the web application will not work as expected. 

However using a Java and the EchoWeb Framework means that the compiled code will always match with what is presented on the web page.  This is because there is no separation of the page presentation and the page validation.  They are both encapsulated inside the Echo classes.  These classes are well tested and will work reliably. 

If you declare a component object and place it in the Echo component hierarchy, its full state will be managed for you.  As you move around different parts of the web application, the objects are up to date, no matter what code path you might have come down.

I discuss Echo and state management further detail in the article When to use Echo and EchoPoint.

Strong state management is one of the key factors in distinguishing a web site (like the one you are currently at) and a web application.  I make the distinction because its very easier to produce web sites. I am currently just typing into a tool called CityDesk and I will press "publish" and ta da...a web site. 

But it is much more difficult to create a great web application.  One that acts in a consistent manner, keeps track of what you are doing and allows you to do it an a fast, easy and logical way.

I believe that using Java and the Echo Web Framework, along with the EchoPoint library, you will get to the goal of great web applications much faster and with a higher degree of quality.

The initial development stage may take a little longer, but doing it right then has major payback later in the all important production deployment time.



SourceForge Logo

The EchoPoint project is kindly hosted by SourceForge