Posted March 13, 2003

Writing distributed applications using the Java 2, Enterprise Edition (J2EE) is not difficult. The architecture for such applications is well defined, and integrated development environments provide wizards and other aids that help you partition the application between display, logic, processing, and data components. In many cases, all you need to do is fill in the automatically generated stubs with your own code. And depending on the complexity of your application, you could have it up and running in a matter of days.

But you live in the real world, where non-technical people use the application to accomplish real work for your employer. You are responsible for making sure the application delivers what was promised from the business perspective, and that means you have to go much further than simply proving its functionality. It must be able to support the business by providing utility to the users, while adding value by improving a process or creating new business opportunities.

So the application built with the IDE wizards and the generated method stubs works fine for the 10 minutes you test it on your desktop, but is too slow to service more than a couple of real users at one time. Or you can't keep the application running for more than a few hours without a failure in the logic or the underlying system. There is a disconnect between what your tools enable you to build, and what you must deploy to meet business needs.

That doesn't mean you should avoid using the tools that the IDE provides to accelerate the development of your application. But it does mean that architecting your application and writing code are only parts of the process of building and deploying an application. Alone, these actions don't guarantee that the application will meet the organization's needs.

If you intend to do more than simply demonstrate a prototype, you must be aware of how your code affects the Java Virtual Machine (JVM) and the underlying system. On behalf of your code, the JVM requests memory, creates objects, releases objects, and runs the garbage collector. Underlying that is the operating system itself, which responds to requests for system resources. All of these actions under the covers will affect your application's reliability and performance, so to make your application production-ready, you have to dig beneath the code. Here are some tips to help you evaluate and improve your application's performance and reliability.

Allocate Memory Wisely