JavaBeans have made it possible for Visual Basic like tools such as Visual Café, JBuilder, Visual Age for Java, and Forte to succeed in the market. These tools all provided a GUI-builder interface where you can drag-and-drop components from a toolbox onto a form, and then add code to define its behavior.
Developing applications using the graphical software development features that these tools provide has not proved as popular with hard-core Java programmers as they have with business-oriented programmers. (We do, however, love these tools for their nice source code editors, project management, and single-step debugging environments.) Many programmers who are comfortable working with classes and APIs don't see the need for graphical software development.
There might be some protectionism in these programmers' attitudes, but there is also some reality in these statements. It is hard to develop code faster than a computer scientist with an IQ over 140 and 10 years of professional programming experience. Unfortunately, the world is not populated with many people who fit into this category. The majority of the computing world is staffed by mere mortals, who often know more about the business of their company than they do about programming.
Many of these people are very bright and more than willing to write their own programs if they don't have to get into the world of polymorphism, serialization, and remote method invocation, and so on. They have no trouble seeing the value of programming tools that enable them to keep their heads on the business at hand.
It is a paradox that most programmers who are capable of creating JavaBeans are not capable of appreciating them. We create these components to accomplish the following goals:
Hide some complexity so that more junior programmers can create applications.
Package business domain specific information so that nonprogrammers can build simple applications.
Promote software reuse.
Integrate with Rapid Development Environments.
Create a division of labor where programmers who understand certain specialties develop code that others who lack their expertise can use.
Another place where components are popular is in companies that have large investments in legacy databases. These companies extend the useful life of the old systems by wrapping the old technology in a Bean wrapper.
It is true that many of these same goals can be accomplished using a traditional Java API. Rather than trying to think of JavaBeans as a replacement for traditional Java classes, try to think of them as an alternative methodology or pattern that is useful for a certain group of classes.
A JavaBean is just another Java class, but it is created to a tighter specification. This specification requires that some methods exist, and what names they can have.
The purpose of this specification is to ensure that every JavaBean can interface with the GUI tools that are available on the market. The following is a list of the features that are required:
Support for introspection Beans must either follow the JavaBean naming conventions, or they must implement the BeanInfo interface and provide a method that describes the Bean.
Must be serializable The Bean instances that are included in a project must be able to be saved and retrieved without any loss of state information.
Must be usable in a visual application builder tool This requirement implies that a toolbox icon and a design-time visual representation must exist.
If a Bean has a runtime appearance, it must extend java.awt.Component (via a subclass like Canvas).
Java Server Pages (JSP) documentation also make use of objects that are called JavaBeans. JSP uses a very limited subset of the JavaBeans specification to provide a simple way of creating classes that JSPs can call directly. In essence, these JavaBeans are simply Java classes with get() and set () methods for all the property values.
Beyond these requirements, a JavaBean is not limited in what actions it can perform. It can contain virtually any processing logic that can be put into other Java classes.