Java has quickly evolved into more than a simple-minded language used to create cute animations on the Web. These days, a large number of serious Java developers are building enterprise-critical applications that are being deployed by large companies around the world. Some applications currently being developed on the Java platform range from traditional Spreadsheets and Word Processors to Accounting, Human Resources, and Financial Planning applications. Because these applications are complex and use rapidly evolving Java technology, companies need to employ a vigorous quality assurance program to produce a high-quality and reliable product. Quality assurance and test teams must get involved early in the product development life cycle, creating a sound test plan, and applying an effective test strategy to insure that these enterprise-critical applications provide accurate results and are defect-free. Accuracy is critical for users who apply these results to crucial decisions about their business, their finances, and their enterprise. I present a case-study of how an effective testing strategy, focused on sub-system level automation, was applied to successfully test a critical real-world Java-based financial application.

THE APPLICATION

The application is being developed by a leading financial services company (hereafter referred to as client) and is targeted toward both individual investors and institutional investors, particularly those investors that are interested in managing their finances and retirement plans. Reliable Software Technologies (RST) provided the QA/Test services and the test team (hereafter referred to as the QA/Test team) to the client.

This the first first in a series of articles focusing on the Swing components that will be released as part of the Java Foundation Classes in JDK 1.2. I'll review the underlying infrastructure for the Swing components, in addition to some of the components Swing has to offer, in my next few installments. This month, after a brief history of the Java Foundation Classes, I'll discuss Swing's implementation of the Model/View/Controller (MVC) architecture.

THE JAVA FOUNDATION CLASSES

In addition to being a vast improvement over its predecessor, the 1.1 AWT lays the foundation for one of the most visible core Java APIs: Foundation Classes (JFC). The JFC consists of the 1.1 (and later) AWT, the Swing components, the 2D API, and the Accessibility API.

HISTORY OF THE JFC

Back in 1995, no one overestimated the impact that Java was about to have on the modern computing world. As a language originally designed for consumer electronic devices, Java was suddenly catapulted into the stratosphere as the language for developing Web software. Over the next couple of years, Java would mature quickly; not only the language but also core packages, such as the AWT.

The original AWT was not designed to be a high powered UI toolkit—instead it was envisioned as providing support for developing simple user interfaces for simple applets. The original AWT was fitted with an inheritance-based event model that did not scale well.

Business application development and deployment using Java has become much more popular in the past year. This is partly because of the redesigned java.awt library in the JDK 1.1, as well as other third-party JDK 1.1-compliant GUI class libraries and IDEs. Developers can now build sophisticated and complex GUI interface front-ends for their applications. As these frontends become heavier, special consideration needs to be given to the deployment strategy used to deploy the client side of a client/server application.

There are several different options available for deploying Java client applications. Some of the options are fairly familiar, while others are not. Even if you understand what options are available, it is not always as obvious which should be used in a given situation. This article reviews options available for client-side deployment of Java applications along with the advantages and disadvantages of each strategy.

TRADITIONAL DEPLOYMENT

In most client/server applications, the deployment options for the client piece of the application is fairly limited. Usually, a client platform and programming language are chosen before development begins and the application is built with the target platform in mind. For example, a telephone invoicing client GUI application could be built using C++ on a Windows NT machine. On completion of the coding for the application, it would have to be manually or remotely installed on every Windows NT client machine that needed to use the application.

Anyone who has ever tried to construct modular, object-oriented user interfaces using the AWT knows how hard it can be. The result can easily end up being difficult to debug, complex to understand and maintain, and certainly not reusable (except by cutting and pasting!). However, huge benefits can be obtained by separating out the user interface from the application code. This has been acknowledged for a long time and the Java Development Kit included the Observer class and the Observable interface to support this. However, with the addition of the delegation event model in the JDK 1.1, the potential for separating the view and control parts of the interface was provided. This allows the separation of the interface from the control elements (i.e., what to do when a user presses a button) and from the application code. Such a separation is often referred to as a model-view-controller architecture (or just as the MVC for short). The MVC originated in Smalltalk, but the concept has been used in many places. This article considers what the MVC is, why it is a good approach to GUI construction, and what features in Java support it. It then describes a GUI application which has been built using the MVC architecture. The source code for this application is provided as an appendix.

The basic synchronization primitives provided in Java are very easy to use, and well-suited to the majority of situations a programmer sees. In many respects they are simpler, easier to use, and less prone to errors than their counterparts in POSIX threads (Pthreads). They do not, however, cover all situations and extending them is not always obvious.

PROVIDING PROTECTION

The first thing that synchronization techniques must provide is a method to ensure that updates to shared data are done in a correct fashion. In particular, many updates comprise several distinct operations and those operations must be done together, atomically. The canonical example is a program that updates your bank account. In Listing 1, it should be obvious that thread number 1 could overwrite the data that thread number 2 had just saved.

The solution to this is to ensure that each of those operations happen atomically. In Java, this is done with a synchronized method (objects with such synchronization are known as monitors). Now the second method will have to wait for the one called first to complete before it can start. The code in Listing 2 will operate correctly.

Pthreads accomplishes the same behavior by using explicit mutex locks. While functionally equivalent, using explicit mutexes suffers from the added complexity of the programmer having to remember which locks to use and to unlock them after use. This is not a big problem, but when writing complex code that has numerous branches and return statements, mistakes do happen (I speak from experience!) and it can be irritating to track down.

Objects are good. Patterns are good. Networks are good.

These statements have almost become IT axioms in the last few years. I'm not going to buck the trend here. Objects are indeed good. Networks and patterns help to make them even better. I'm going to show a relatively easy way to link these three things together.

Well designed object-oriented applications share a common topology (see Riel, A. Object-Oriented Design Heuristics. Addison-Wesley, 1996.) By topology I mean the natural features of an entity and their structural relationships. A well-planned object model will spread out the application logic within a system. Related data and behavior will be kept in logical, isolated units. Structuring applications in this way promotes reuse, facilitates comprehension, and minimizes the effects of change.

One side effect of partitioning a system in this way is the need for these “logical isolated units” to communicate with each other. Using controller classes to organize the communication is not a viable solution because it concentrates the system's intelligence in a single place. How can we share information without cluttering our design?

The Observer pattern (see Gamma, E., R. Helm, R. Johnson, and J. Vlissides, Design Patterns: Elements of Reusable Object-Oriented Software. Addison-Wesley, 1995.) provides a possible answer to our question. In the applicability section of the pattern description we find that Observer is a good way to “notify other objects without making assumptions about who these objects are.

The java developers' slogan is “100% Java,” meaning “Don't taint your Java software by incorporating non-Java components.” Yet, Java itself is neither 100% pure object nor 100% pure object-oriented; it is “tainted” with components of the procedural programming paradigm. The Java designers have borrowed many ideas from diverse sources—other object-oriented languages, especially C++ and Smalltalk, design patterns (see Gamma, E. et al. Design Patterns: Elements of Reusable Object-Oriented Software, Addison-Wesley, 1995), and basic object-oriented design principles—picking and choosing good ideas from each. And they've done a truly fine job. However, at one particular juncture, I believe the language architects made the wrong choice, and that was the decision to incorporate non-object primitive types into the otherwise uniform object-oriented language model.

There are two types of types in Java. By primitive types, I mean elementary variable types such as int, boolean, float, long, short, and so on. These are sometimes referred to as “built-in” types. The other type of type is objects: a variable can be declared to be of type Object or String or any other class. Referring to the two types of types as metatypes, we have primitive and object metatypes (the truth is, the two metatypes are primitive and reference, which includes not only objects, but interfaces and arrays—more on why they are “reference” types later). By incorporating both metatypes, Java is not populated purely with objects.

TheJava Report published its first issue in March 1996. This was a real accomplishment when you consider that it was only on May 23, 1995, that John Gage, director of the Science Office for Sun Microsystems, announced Java to the world at SunWorld. Later in 1995, Sun released the initial Java Development Kit (JDK) and a Java enabled Web Browser called HotJava. The rest is history, as Java is now firmly entrenched in the computing industry. Many of us who saw demonstrations of Java in 1995 knew that it was something new, something different, and something not to be ignored. Those behind the Java Report knew this too, and we have been reporting on Java ever since.

In his first editorial for Java Report, the original Editor-In-Chief, David Fisco, wrote:

Recently, the subject of patterns has become one of the hottest topics in object-oriented development. The most well-known patterns are the design patterns of the Gang of Four (Gamma, E., R. Helm, R. Johnson, and J. Vlissides, Design Patterns: Elements of Reusable Object-Oriented Software, Addison-Wesley, 1994), fundamental implementation patterns that are widely useful in object-oriented implementations. An important part of most OO systems is the domain model—those classes which model the underlying business that the software is supporting. We can see patterns in domain models too, patterns that often recur in surprising places. I will provide a short introduction to some analysis patterns that I have come across.

I'm not going to do this by surveying the field, or discussing theory—patterns don't really lend themselves to that. Rather, I'll show you some examples of patterns and illustrate them with UML diagrams (Fowler, M., UML Distilled: Applying the Standard Object Modeling Language, Addison-Wesley, 1997) and Java interface declarations.

REPRESENTING QUANTITIES

Imagine you are writing a computerized medical record system for a hospital. You have to record several measurements about your patients, such as their height, weight, and blood-glucose level. You might choose to model this using numeric attributes (see Figure 1 and Listing 1).

This approach is quite common, but may present several problems. One major problem is with using numbers.

Javabeans are reusable software components that are assembled using a visual assembly tool to create Java applets or applications. The JavaBean standard provides a software component architecture for Java that promises to deliver rapid application development (RAD) by enhancing reuse and increasing the abstraction level of software development, enabling even non-programmers to develop Java applets and applications. JavaBeans derive power because one can configure and connect beans to achieve sophisticated functionality without knowing all of the internal details of beans themselves.

In principle, a bean may be used by just knowing “what” it does without necessarily knowing “how” it works. For example, a loan calculator bean can calculate the principal and interest due on a loan. Generally, this is sufficient information to use the bean without having to know the details of the algorithm the bean uses. However, this requires some measure of trust on the part of the person using the bean. To draw again on the loan calculator bean example—if the configured loan calculator bean says we need to make a payment of $550 per month for the term of the loan, we need to trust that this result is correct without meticulously working through the beans implementation to ensure it calculates correctly. Clearly, without this trust the bean loses much of its power as a software component for reuse and RAD, and worse still, fuels the “not invented here” syndrome.

Testing is not closely integrated with development. This prevents you from measuring the progress of development—you can't tell when something starts working or when something stops working. Using JUnit you can cheaply and incrementally build a test suite that will help you measure your progress, spot unintended side effects, and focus your development efforts.

THE PROBLEM

Every programmer knows they should write tests for their code. Few do. The universal response to “Why not?” is “I'm in too much of a hurry.” This quickly becomes a vicious cycle—the more pressure you feel, the fewer tests you write. The fewer tests you write, the less productive you are and the less stable your code becomes. The less productive and accurate you are, the more pressure you feel.

Programmers burn out from just such cycles. Breaking out requires an outside influence. We found the outside influence we needed in a simple testing framework that lets us do a little testing that makes a big difference.

The best way to convince you of the value of writing your own tests would be to sit down with you and do a bit of development. Along the way, we would encounter new bugs, catch them with tests, fix them, have them come back, fix them again, and so on. You would see the value of the immediate feedback you get from writing and saving and rerunning your own unit tests.

A basic problem with most current Java implementations is that they were designed to support very small applet-style programs. The ability to effectively execute very large, computationally complex application programs is not currently an area of strength for Java. However, Java is now being used as a general-purpose language for implementing all types of programming problems including computationally intense applications. The translation and execution techniques used by current Java implementations do not necessarily scale to support the performance requirements of such programs. Static compilation with aggressive optimization is an implementation technique that is commonly used for languages such as C, C++, and FORTRAN but has not been widely used to implement Java. This article identifies some of the reasons for Java's performance problems and examines how static compilation and optimization techniques can be applied to Java to alleviate these problems.

WHY DOES JAVA HAVE POOR PERFORMANCE?

Java's performance problems can be traced to two major sources: the inherent inefficiencies of object-oriented (OO) programming constructs and the use of a virtual machine (VM)-based implementation strategy. After explaining the details of these inefficiencies I show how static compilation technology is able to overcome them.

OO LANGUAGE INEFFICIENCIES

OO programming languages such as Java have been widely promoted as key tools for increasing programmer productivity. The productivity improvements of OO languages are generally achieved through code reuse. Using an OO language such as Java, a programmer needs to write less new code because OO languages support and encourage the reuse of existing code.