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:

At Rogue Wave, we sell C++ and Java software components. We have always included source code with our products. Customers often browse through the code to get a feeling, not just for how it works, but for how to write good software. As a result, we have always felt pressure—maybe more pressure than most companies—to have good, consistent style throughout our source code.

As the company grew, making sure programmers were all following the same rules became difficult. To address this, our founder and first programmer, Tom Keffer, wrote 35 pages that explained how we write C++ code at Rogue Wave. We passed the document around and made sure new hires got a copy. It worked. When customers asked how we maintained consistency in our coding, we told them about Tom's “C++ Design, Implementation, and Style Guide,” and sent them a copy. Word spread and we turned Tom's document into a technical report. We sent out thousands of copies and received terrific positive feedback.

When Java came along, we decided we needed a document like the “C++ Guide.” A note went out to our internal [email protected] mailing list soliciting rules for Java use that we should be using. The resulting list of rules became the first draft of the “Rogue Wave Java Style Guide.”

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.