The current industry buzz is that the Java utilities to create a GUI are not powerful enough for industrial-strength applications. This is correct if you disregard two major issues. One is the advent of the JavaBeans specification by JavaSoft, a division of Sun Microsystems. The other is the widespread availability of powerful GUI JavaBeans components from a variety of software vendors.

This article provides an overview of the JavaBean specification and gives examples of JavaBean components from several vendors. After reading this article, you might consider creating your own JavaBeans or procuring some from a JavaBean supplier. Whatever you do, you will see that the JavaBean technology will significantly impact Java development. The simplicity of the JavaBean specification will enhance the progression of Java as the object-oriented (OO) language of choice.

Unless you've been marooned on some tropical island in the middle of the Pacific, you are aware of the visual programming techniques in widespread use today. AS/400 programmers are most familiar with Visual Basic (VB) or perhaps Visual RPG, but C++, PowerBuilder, and other programming environments, including Java, also provide visual development tools. The ability to visually build graphical applications lessens the technical expertise necessary to design and create them. Besides, building a visual interface by coding with traditional text editors is silly; visual applications should be designed using visual design tools.

Most major Java Integrated Development Environments (IDEs) come with a visual editor. IBM's VisualAge for Java calls its the Visual Composition Editor. A visual editor presents a toolbar of visual components that you can drop onto a visual representation of a panel under construction. Standard Java comes with a package of GUI components called the Abstract Window Toolkit (AWT) that provides basic graphical components. Java IDEs such as Asymetric's SuperCede, Symantec's Visual Café, and IBM's VisualAge for Java provide toolbars that contain the standard AWT components (e.g., label, text field, text area, button, check box, radio button, list, choice, horizontal scroll bar, vertical scroll bar, and canvas).

With these components, it is possible to visually design the application, and, for the most part, eliminate the need to write Java source code-the IDE automatically produces the code to enable the components you place into the application. However, the AWT components do not provide the power, flexibility, and robustness of other graphical programming environments, such as those that target Windows. This is where JavaBeans can help.

When JavaSoft first began creating the JavaBeans specification, the company offered the following mission statement: "Write once, run anywhere, reuse everywhere." As a result of JavaSoft's efforts, the JavaBeans specification is available today as a standard method for Java component design.

Components are reusable pieces of software that you can easily assemble to create applications, thereby providing greater development efficiency than you'd have if you developed the software yourself. If you program in VB, you are familiar with OCXs and their VBX predecessor. OCXs are powerful components often written in C++ to follow Microsoft's component strategy. JavaBeans are similar to OCXs, but they have the notable advantage of having been developed entirely from scratch, with no limitations imposed from a prior technology. JavaBeans also have the advantage of being able to "run anywhere," literally on any machine with a Java Virtual Machine (JVM).

Before I discuss the JavaBean specification, let's look at some example JavaBeans from an example provider. Stingray Software has a group of JavaBeans lumped into one product, ObjectiveBlend. These JavaBean components are not unique; they are similar to what many other JavaBean suppliers provide.

Figure 1 shows VisualAge for Java's Visual Composition Editor with VA's parts palette sporting Stingray Software's JavaBeans. The second column of the parts palette shows the four JavaBean components that I selected from ObjectiveBlend: a Tabbed Dialog, a Tree, a MaskEdit, and a DateEdit. These standard graphical components are very useful tools to a graphical programmer. For example, the Tabbed Dialog allows you to effortlessly create tabbed dialogs similar to those of Windows 95. As an experienced Windows GUI programmer, I would not want to program Java GUIs without tabbed dialogs-they simply improve the intuitive nature of an application too much to design without them. The Tree allows you to create a tree graphic similar to that of Windows Explorer. You might use a tree to display something like a bill-of-materials to support visual expansion and compression of selected assemblies. The MaskEdit-well, I'll get to that later. The DateEdit JavaBean does just what you would expect but then surprises you with the ability to pop up a calendar month dialog that allows visual selection of a date.

Stingray Software is simply one of many JavaBean suppliers that has catered to the C and C++ markets for years, with OCXs and other component technologies; there are many other JavaBean suppliers. You can search an expanding list of JavaBeans-based products by name, company, or category at http://java.sun.com/beans/directory/.

Many of the vendors listed at this site have converted their C and C++ component technologies to 100-percent-pure JavaBean code that is fully compliant with the JavaBean specification. Some JavaBean vendors have created Java classes that simply enclose existing C++ components. Such components were built with specific operating system technologies, such as Microsoft's ActiveX. They work fine as long as you don't mind confining your Java application to Windows 95 or NT

workstations. But, if you want your application to "run anywhere," stick with JavaBeans that are 100-percent-pure Java.

Note that one significant vendor of JavaBeans is JavaSoft, the creator of Java. JavaSoft recently announced a powerful set of components known as the Java Foundation Classes (JFC). The JFC is a complete GUI toolkit of JavaBeans that dramatically extends and otherwise improves the original AWT with a comprehensive set of classes and services-bad news for the other JavaBean suppliers because JFC is expected to become an integral part of Java 1.2. (By the time you read this, the beta JDK 1.2 should be available for download from the Web.)

Of the four components presented in the parts palette in Figure 1, I described only three. I purposely left out one of the simple components-the MaskEdit JavaBean. This component sets numeric editing, similar to the edit word of AS/400 DDS. Figure 1 shows VA's Visual Composition Editor with a MaskEdit JavaBean dropped into the visual editor panel. The Property Editor shown allows you to set the "properties" for that implementation of a MaskEdit. Properties are kept internal to the JavaBean as private object member variables to store the states that represent and control the behavior of the JavaBean. In this case, I have set the mask to list a dollar sign and thousands separators and to allow only two decimals.

The first thing I wanted to do when I saw this JavaBean was to create my own JavaBean to provide an RPG-like edit code. Rather than enter a mask property, we RPG veterans would prefer to specify a simple edit code. This proposed JavaBean could easily inherit from the MaskEdit's JavaBean classes to expedite delivery of the component, but we also have the alternative of writing it from scratch. Actually, you would be surprised at how easy it is to create an EditCode component and other simple JavaBeans. This brings me to my next discussion-the JavaBean specification.

By following JavaSoft's JavaBean specification when developing my hypothetical EditCode JavaBean, I can create a component that is compact, easy to use, fully portable, built on the inherent strengths of Java, and adaptable to any Visual IDE that supports Java 1.1.

A full-featured JavaBean is required to support the following major services: event handling, property management, introspection, persistence, and IDE support. Property management relates to the JavaBean method of exposing a component's data members. A JavaBean exposes its object's data members through object functions known as getter methods and setter methods. These accessor methods must follow naming conventions, but they are really nothing more than encapsulation techniques considered standard in many OO programming languages. The accessible data members are known as properties.

I studied JavaBeans before I started to learn about the new event-handling model of Java 1.1. I was pleasantly surprised to see that the JavaBeans' event-handling methods were exactly the same as Java 1.1's. This immediately broadened the impact of my newfound knowledge. The primary goal of the event-handling model in the Java 1.1 API is to provide an extensible means of sending event information from one component to one or more other components or applications.

The Java 1.1 event-handling mechanism adopted by the JavaBean specification follows the source/event/listener design pattern (Figure 2). An object that is capable of generating events is

considered an event source. An application or object that reacts to an event is considered an event listener. And the event itself is encapsulated as an actual Java object. That event object contains data members that clarify the event. An event source registers event listeners with a simple function call. When the JavaBean event source generates an event, a specified function is called on the event listener with an event object as a parameter. For instance, with my proposed EditCode JavaBean, I would have a text entry object as the event source. One event might be the KeystrokeEvent that holds the value of the character pressed, which the EditCodeListener receives and reacts to by editing the value. This separation of listener and source seems overkill for the EditCode bean, but, by following the JavaBean specification, I enable runtime extensibility of the JavaBean.

It is not my intent to publish the complete JavaBean specification, as you can download it from http://www.javasoft.com. Nevertheless, I would like to list the property specification design patterns to give you a taste for the simplicity of the overall JavaBean specification.

The JavaBean specification is formalized through a set of design patterns. Design patterns are a hot topic in OO circles. If you aren't familiar with the concept of design patterns, think of them as formal descriptions of solutions to recurring computing problems. The following design patterns are used as templates for the naming of the JavaBean get and set accessor functions for simple atomic properties, Boolean properties, and arrays of properties:

Simple Atomic Properties
public get();
public void set( PropertyType p);
Boolean Properties
public boolean is();

Arrays of Properties
public get(int I);
public [] get();
public void set(int i, p);
public void set( [] p);

The notation is the notation used by the JavaBean specification to mean "insert your whatever name here." For instance, my EditCode JavaBean might have three properties: a float Value, a Boolean Positive, and the character array Digits. I would then define the following functions:

// to retrieve a value
public float getValue ();

// to change a value via.float parameter
public void setValue (float p);

// to return a boolean query of whether the value is positive
public boolean isPositive ();

// to retrieve the character at index i
public char getDigits (int i);
// to retrieve character array of digits
public char[] getDigits ();

// to change the character at index i to value p
public void setDigits (int i, char p);

// to change the character array to values of the passed array
public void setDigits (char[] p);

Some of a JavaBean component's properties can be defined as bound or constrained properties. A component with a bound property sends change notifications to objects that are registered with the JavaBean and are, in effect, listening for property changes. These "listener" objects can then react to modifications to the property's value. A constrained property also has change notifications sent, but its JavaBean must then be prepared to handle change rejections from the

listening objects by reverting the property back to its previous value.

I would have to specify both bound and constrained properties for my hypothetical EditCode JavaBean. The numeric value that the EditCode JavaBean is editing would be bound to a function that wants notification when the value changes. That function "listens" for change notifications from the EditCode JavaBean and then perhaps updates an associated database field with the new value. But I would also impose constraints on the value within the EditCode bean- after all, I am editing it. My EditCode JavaBean would have to support the registration of Vetoable Change Listeners and provide for the handling of potential vetoes to changes. An example of a veto might be a case in which someone typed one too many decimals or in which the value exceeded a range. EditCode's value property's set accessor method would be designed to broadcast notifications of changes to all the registered Vetoable Change Listeners. The Vetoable Change Listeners may choose to veto a change by throwing a Java exception. EditCode's set accessor methods must also be coded to catch or handle the exceptions and to revert the changed properties back to their original values.

So far, I have given you a flavor for how JavaBeans are programmed to allow access to properties. I have also covered a good bit about bound properties and even a little about constrained properties. You also now know that these techniques are exactly the same as in the Java 1.1 event-handling mechanism. You might then think that I have not talked about anything specific to JavaBeans. But I have; by following the event source, event, and event listener object design patterns, I have enabled the JavaBean introspection services. The JavaBean introspection facilities enable IDEs to query a JavaBean for its internal structure. The IDE then becomes aware of that bean's data properties and functional API. Introspection of a JavaBean is mostly done simply by examining the bean's get and set accessor functions. This approach greatly simplifies JavaBean construction, because you do not have to laboriously define the component's properties and interfaces as you would when creating components with OCX and OLE technology.

A Java IDE that supports JavaBeans can invoke the introspection services to expose a JavaBean's properties and methods visually. The JavaBeans inspector simply looks at a new JavaBean for implementation of JavaBean design patterns. For instance, any get and set accessor methods implementations tell the introspector the name and data type of the properties in a bean. The JavaBean specification does have explicit methods of exposing the properties and services of a JavaBean to IDEs with its BeanInfo class, but the implicit ability of the JavaBean introspection facility often makes defining a BeanInfo class unnecessary.

One of the major services that a full-featured JavaBean is required to provide is persistence. Persistence is simply the capability of an object to save and restore its object state (data members) to and from storage. We are used to making data persistent with a database file, but a software component does not fit into the database scheme. The persistence facilities of Java do. The persistence mechanism was built in to Java to allow objects to save their properties to external storage through a process known as serialization. Once the object has saved or serialized its properties to a file, it is considered persistent because it transcends the invocation of the program. Serialized objects are important for Web applications, because they can be transferred across a network.

Where do you keep your JavaBeans? In a JAR (or Java Archive), of course. JavaBeans are distributed with JAR files, which are nothing more than JavaBeans compressed using the ZIP

format. Using JAR files is the preferred method of distributing JavaBeans, but it is also a way to improve download performance for Java applets from the Web using HTTP. The Bean Development Kit (or BDK, which is available as a free download from the JavaSoft Web site) comes with a JAR tool that has a variety of options for packaging and compressing JavaBeans to a JAR file. When the JAR utility is executed, it automatically creates and stores a Manifest file that contains meta information about the JavaBeans being compressed. This Manifest file is then used by Java IDEs when installing JavaBeans into the interactive programming environment.

The IDE installation procedure for JavaBeans may vary somewhat from vendor to vendor. For some products, it may be as simple as copying a JavaBean JAR file to the jars directory for the IDE.

The installation procedure for IBM's VisualAge for Java does not follow this method, but it is, nonetheless, trivial. VisualAge allows you to import JAR files with the File menu's Import option. The Import facility then prompts you to specify the name and location of the JAR to import (Figure 3). VisualAge then adds the JavaBeans in the JAR file to its object repository. Then, you add them to your toolbar by selecting the following from the menu: Options, Modify Pallette, and Add New Category (Figure 4) followed by Add to Pallette (Figure 5). Figure 6 then shows the Visual Composition editor with RogueWave's CellGrid JavaBeans added.

RogueWave's CellGrid is just one example of a wide variety of grid components. Third-party vendors have been selling grid components for years, because their grids are far more powerful than any component delivered from most graphical language's IDEs.

I have programmed two applications that used grids from a third-party vendor. One used RogueWave's CellGrid and another used Stingray's ObjectiveGrid. To date, a grid is as close as your Java IDE can come to mimicking an AS/400 subfile. Grids also have some interesting additional features that exceed what your AS/400 subfile could ever do. Your database records retrieved from a DB2/400 file can be placed in grid rows with a column for each field you wish to display. But with a grid, you can also specify a different JavaBean for each column to do a variety of edits. For instance, a grid's dollar field column might have one JavaBean specified but then a date field's column could have a date JavaBean assigned. As this article goes to press, SunSoft's AWT replacement components package, Java Foundation Classes (JFC), is in beta; it too contains a powerful grid. Look for an upcoming Java article on subfile programming techniques using SunSoft's JFC JTable grid and IBM's AS/400 Java Toolkit.

Whether you make or buy your JavaBeans, JavaSoft's JavaBean specification will improve your development process. JavaBeans allow you or a JavaBean supplier to shrink-wrap powerful components that are compact, easy to use, and fully portable. The JavaBean specification is relatively new, but, at a recent Netscape development conference, 65 major companies disclosed support for JavaBeans. These companies include such names as IBM, Oracle, Sybase, and Hewlett-Packard (HP). It is obvious that JavaBeans are here to stay, judging by the financial backing of such powerful companies, the recent availability of JavaBeans from vendors like Stingray and RogueWave, and the ease with which we can develop our own JavaBeans.

Don Denoncourt has worked on the AS/400 since its inception. He has 15 years experience in RPG and COBOL, 10 years experience with C, and 5 years object-oriented programming experience with C++. Don feels that Java is the future of object-oriented application

programming on the AS/400. He can be reached at This email address is being protected from spambots. You need JavaScript enabled to view it..

Figure 1: Here, VisualAge for Java's Visual Composition Editor sports Stingray Software's JavaBeans

Figure 2: Java 1.1's event-handling model follows the source/event/listener design pattern

Figure 3: IBM's Visual Age for Java's import dialog makes JavaBean installation simple

Figure 4: Add a new toolbar category from this screen

Figure 5: Add a JavaBean to a toolbar category from this screen

Figure 6: This screen shows the Visual Composition Editor with RogueWave's CellGrid

Don Denoncourt is a freelance consultant. He can be reached at This email address is being protected from spambots. You need JavaScript enabled to view it..

---

MC Press books written by Don Denoncourt available now on the MC Press Bookstore.

		Java Application Strategies for iSeries and AS/400 Explore the realities of using Java to develop real-world OS/400 applications. List Price $89.00 Now On Sale

Also Read

Practical Java: Start Your Java Engine!

Practical Java: Making Java Work for You

Book Review: Java for RPG Programmers