JavaBeans Development Kit Components

The JavaBeans Development Kit (BDK) encompasses a suite of components designed to aid in the development, testing, and deployment of JavaBeans, which are reusable software components adhering to a set of conventions specified by the JavaBeans architecture. The primary components of the BDK include:

1. BeanBox: BeanBox is the centerpiece of the BDK, functioning as an interactive testing container and development environment for JavaBeans. It allows developers to visually assemble beans, connect their properties and event handlers, and test their functionality in a dynamic, graphical setting. BeanBox facilitates the rapid prototyping and testing of beans, enabling developers to experiment with component layouts, event handling, and property manipulations without writing extensive test code.
2. Property Editors: Property editors are specialized tools within the BDK that provide graphical interfaces for editing the properties of beans. These editors allow developers and users to configure bean properties in a more intuitive and user-friendly manner, especially for complex properties that may not be easily represented by simple text or numeric values. Property editors enhance the usability of beans by abstracting the complexity of property configurations into more manageable graphical interfaces.
3. Customizers: Customizers are advanced GUI components associated with specific beans, offering detailed interfaces for configuring and customizing those beans' properties and behavior. They go beyond the capabilities of standard property editors by providing a bespoke configuration environment tailored to the unique requirements of each bean. Customizers enable a higher degree of customization and are particularly useful for complex beans that require intricate setup processes.
4. Introspection Tools: Introspection tools are part of the BDK that facilitate the examination and discovery of a bean's properties, events, and methods. These tools utilize the JavaBeans introspection APIs to dynamically analyze beans, identifying their capabilities and interfaces. This feature is crucial for understanding the functionality of beans, ensuring adherence to JavaBeans conventions, and facilitating the integration of beans into application development environments.
5. Documentation and Sample Beans: The BDK is accompanied by comprehensive documentation that covers the JavaBeans architecture, the functionality of the BDK components, and best practices for bean development. Additionally, a collection of sample beans is included, serving as practical references and learning aids for developers. These samples demonstrate various aspects of JavaBeans development, such as property management, event handling, and customizer implementation, providing valuable insights into effective bean design and usage.
6. Serialization Support: Support for serialization within the BDK enables beans to maintain their state across different sessions by allowing their properties and state to be saved and later restored. This capability is essential for developing persistent components that can be reused and redeployed across multiple applications and environments.

The JavaBeans Development Kit, through these components, offers a robust and comprehensive environment for developing JavaBeans. It simplifies the process of bean creation, customization, and integration, fostering the development of modular, reusable software components that can enhance the functionality and maintainability of Java applications.

The BDK contains both information and tools to aid you as you design and develop JavaBeans components.
Select a part of the BDK to learn more about it:

The BDK includes a variety of different example Beans with complete source code. These Beans demonstrate many different aspects of the JavaBeans technology. Some of them even include source code in HTML form with color syntax highlighted code to make certain aspects of the code easier to understand. You can use the example Beans as starting points for Beans of your own. The source code for the BeanBox test container is also provided in the BDK.

package com.java.beans;
public class TempChangedEvent extends java.util.EventObject{
 // the new temperature value in Celsius
 protected double theTemperature;
 // constructor
 public TempChangedEvent(Object source, double temperature){
  // pass the source object to the superclass
  super(source);
  // save the new temperature
  theTemperature = temperature;
 }
 // get the temperature value
 public double getTemperature(){
  return theTemperature;
 }
}

The constructor for the TempChangedEvent class takes the source object and new temperature value as parameters. The source object is passed on to the superclass and the new temperature is stored. The method getTemperature() is provided to allow the new temperature value to be retrieved from the object. We will see in a later module that the getTemperature() method actually conforms to the design pattern for read-only properties.

The BDK includes the complete source code for the JavaBeans API, which is technically part of the core Java 1.1 API. Although this source code is also available with the JDK 1.2, the BDK isolates the specific classes that comprise JavaBeans API. JavaBeans technology is the component architecture for the Java 2 Platform, Standard Edition (J2SE). Components (JavaBeans) are reusable software programs that you can develop and assemble easily to create sophisticated applications. JavaBeans technology is based on the JavaBeans specification.

BDK 1.1 contains an updated version of the BeanBox and some new sample Beans. The BeanBox is both a BeanContextcontainer and a BeanContext ServiceProvider. The BeanBox provides a simple mechanism for propagating its execution environment to its contained Bean:

Design-time, run-time toggle.

The BeanBox also provides two services:
An InfoBus service (for the InfoBus 2.0). A method tracing service, discussed here in detail. The BeanBox publishes the method tracing service. The Juggler Bean looks for this service and uses it to report on certain methods. The Juggler connects during instantiation to the method tracing service. Then methods such as paint(), startJuggling() and stopJuggling() use the service to post a message in the Method Tracing Window. The BeanBox publishes the run-time/design-time toggle as a BeanContext service. When design-time is disabled, the method tracing service is suspended.

Question: Was the "InfoBus 2.0 Service" everl part of the JavaBeans specification?
The "InfoBus 2.0 Service" was never actually part of the official JavaBeans specification, even though it was sometimes marketed as such. It was an optional add-on component developed by Sun Microsystems (now Oracle) and included in some Java Development Kits (JDKs).
Here's a breakdown of the InfoBus:

1. Not part of core specification: The core JavaBeans specification, defined by Sun (now Oracle), never included the InfoBus 2.0 Service. It focused on the core components you mentioned earlier: data (properties) and methods.
2. Optional add-on: The InfoBus was a separate technology, although it leveraged JavaBeans conventions and could be used with them. It aimed to simplify distributed communication between JavaBeans components.
3. Deprecated: The InfoBus technology itself has been deprecated since Java 2 Platform, Standard Edition (J2SE) 1.4. This means it's no longer actively supported or recommended for new development.

While the InfoBus might have been introduced alongside JavaBeans, it was never a core part of the specification and is now considered outdated. If you're working with modern Java development, you won't encounter or need the InfoBus service.

When a human has customized the behaviour of a set of components, the application builder should use the persistence mechanisms to store away the state of the components. When the application is run, this pickled state should be read back in to initialize the components.

Class and interface discovery is the mechanism used to locate a component at run-time and to determine its supported interfaces so that these interfaces can be used by others. The component model must also provide a registration process for a component to make itself and its interfaces known. The component, along with its supported interfaces, can then be discovered at run-time. Dynamic (or late) binding allows components and applications to be developed independently. The dependency is limited to the "contract" between each component and the applications that use it; this contract is defined by interfaces that the component supports. An application does not have to include a component during the development process in order to use it at run-time; it only needs to know what the component is capable of doing. Dynamic discovery also allows developers to update components without having to rebuild the applications that use them. This discovery process can also be used in a design-time environment. In this case, a development tool may be able to locate a component and make it available for use by the designer. This is important for visual programming environments, which are discussed later. In the next lesson, I will discuss how to run the BeanBox test container and the different parts of its user interface.