To understand the precise meaning of this definition of a Bean, clarification is required for the following terms:

• Software component
• Builder tool
• Visual manipulation

Reusable Software Components

Reusable software components are designed to apply the power and benefit of reusable, interchangeable parts from other industries to the field of software construction. Other industries have long profited from reusable components. Reusable electronic components are found on circuit boards. A typical part in your car can be replaced by a component made from one of many different competing manufactuers. Lucrative industries are built around parts construction and supply in most competitive fields. The idea is that standard interfaces allow for interchangeable, reusable components.

Reusable software components can be simple like familiar push buttons, text fields list boxes, scrollbars, dialogs, for example

Button Beans

Slider Beans

Spinbutton Beans

These are the kinds of component sets, toolkits, or widget libraries traditionally sold by third parties. Lately we've seen vendors selling more complex software components like calendars,

and spreadsheets:

If you have used visual component assembly tools such as Visual Age, Delphi, Visual Basic, PARTS, Mojo, or even PowerBuilder, you are familiar with the notion of software components. Visual Basic Extensions (VBX's) were the first widely used software components, followed shortly by language-independent OLE Custom Controls (OCXs). UNIX programmers will be more familiar with widgets and toolkits.

Reusable components add standardized interfaces and object introspection mechanisms to widgets allowing builder tools to query components about their properties and behavior. Software components need not be visible in a running application; they only need to be visible when the application is constructed.

For example, the builder tool above shows a calculator component that is built from 16 button components, a text field component, and a panel upon which the buttons and a text display are placed. In addition, you can see five invisible components. These specific components hold values or strings used by the calculator for intermediate calculations, operation codes, and display strings, as well a boolean flag to determine when evaluation of a new expression is started.

A programmer can move, query, or visually hook together components such as numeric value holders, disk accessors, or network socket components with a mouse while operating a builder tool. However, such components would do their work invisibly while the application is running.

With Beans, you can purchase custom components for Java from third parties. You can also purchase builder tools or application contruction programs supporting Beans Application construction tools let you you to build Java applications by visually selecting components from pallets, panels, or menus, drop them into a form, or client window, and hook up events to event handlers using the mouse as your primary input mechanism.

Components can be nested and arbitrarily complex. For example, a calculator built from components becomes, itself, a component. Custom-built components are easily added to builder tool palettes. More complex components include barcharts,

graphical diagram editors,

and word processors:

Beans, Widgets, Controls, and Components

Depending on your background, you may use different words to describe GUI components for a given software platform. If you come from a Windows background, you probably think in terms of visual controls, possibly Visual Basic Extensions (VBXs) or OLE Controls (OCXs) and now Active X Controls. If you're more accustomed to environments like Motif or X Windows, you probably think in terms of toolkits or widgets.

Beans are to widgets as VBXs or OCXs are to native Windows controls. The main difference between Beans and native platform controls is that they define a design-time interface, which allows application designer tools, or builder tools to query components and ask them what kinds of properties they define, as well as what kinds of they can generate or respond to.

In visual application builder environments Beans are sometimes referred to as reusable software components, or custom controls.

The main thing that distinguishes software components from standard Windows controls, or Motif widgets is their packaging. Software components or custom controls are packaged with design-time information (properties and methods) that allow builder tools to determine their capabilities.

A second difference is that end users, or third party suppliers can build custom beans independently of the maker of the GUI platform or operating system. These third-party components can then be distributed by IS departments to internal enterprise clients, or they can be sold as add-on components to anyone who uses builder tools to construct applications.

Beans or Class Libraries

"What is the difference between a Java Bean and an instance of a normal Java class?"

What differentiates Beans from typical Java classes is introspection. Tools that recognize predefined patterns in method signatures and class definitions can "look inside" a Bean to determine its properties and behavior. A Bean's state can be manipulated at the time it is being assembled as a part within a larger application. The application assembly is referred to as design time in contrast to run time. In order for this scheme to work, method signatures within Beans must follow a certain pattern in order for introspection tools to recognize how Beans can be manipulated, both at design time, and run time.

In effect, Beans publish their attributes and behaviors through special method signature patterns that are recognized by beans-aware application construction tools. However, you need not have one of these construction tools in order to build or test your beans. The pattern signatures are designed to be easily recognized by human readers as well as builder tools. One of the first things you'll learn when building beans is how to recognize and construct methods that adhere to these patterns.

Not all useful software modules should be Beans. Beans are best suited to software components intended to be visually manipulated within builder tools. Some functionality, however, is still best provided through a programatic (textual) interface, rather than a visual manipulation interface. For example, an SQL, or JDBC API would probably be better suited to packaging through a class library, rather than a Bean.

Basic Bean Concepts

Individual Java Beans will vary in functionality, but most share certain common defining features.

• Support for introspection allowing a builder tool to analyze how a bean works.
• Support for customization allowing a user to alter the appearance and behavior of a bean.
• Support for events allowing beans to fire events, and informing builder tools about both the events they can fire and the events they can handle.
• Support for properties allowing beans to be manipulated programatically, as well as to support the customization mentioned above.
• Support for persistence allowing beans that have been customized in an application builder to have their state saved and restored. Typically persistence is used with an application builder's save and load menu commands to restore any work that has gone into constructing an application.

While Beans are intended to be used primarily with builder tools, they need not be. Beans can be manually manipulated by text tools through programatic interfaces. All key APIs, including support for events, properties, and persistence, have been designed to be easily read and understood by human programmers as well as by builder tools.

My Interpretations

Basically all of these different libraries or frameworks are already written and applied code that can be manipulated using a graphical program. It is an easier way of animating different objects within the windows environment. I only really know how the VCL performs, so I cannot really give an objective opinion on which way is better. I believe that they all seem basically like "different ways of doing the same thing". The choice of which one is better is made by which form the programmer can manipulate better. I mean if you are an expert at one form then why not keep using what you are good at.

I have never used Visual Basic or done any Java programming, but in my spare time I do plan on trying to learn them. They seem like any other language, once you learn the basics the programming part should become routine. What you don't know or remember should be easy enough to look up or ask a news group that should be able to answer almost any question you have.

While doing my research I found the easiest information was about Java, then the VCL and finally Visual Basic. I do not know why this is, but my guess is that Java is a relative newcomer to the group, and there are more facts and how to's about something that is new to the market, than something that has been around awhile.

I recommend using Deja News. Anything you need to know can be looked up or asked in the news groups.