In diesem Kapitel wurde die JavaBeans-Technologie vorgestellt. Diese Technologie stellt eine erweiterte Funktionalität von Java dar, mit der wiederverwendbare Software-Komponenten in Java realisiert werden können. Der Leser sollte nach der Lektüre dieses Kapitels in der Lage sein, Komponenten-Software in Java zu schreiben.

Themenschwerpunkte des Kapitels sind die Beschreibung des Event-Modells von JavaBeans, die Bearbeitung von Eigenschaften, die Bereitstellung von Beans-Informationen, mit denen eine Verarbeitung in Entwicklungsumgebungen stattfindet, sowie die Vorgehensweise zur Abspeicherung des Zustand eines Beans. Die Bearbeitung von Beans innerhalb einer Entwicklungsumgebung wurde anhand des Bean Development Kits (BDK) verdeutlicht.

Den Abschluss des Kapitels bildet das Anwendungsbeispiel, in dem (aufbauend auf das im Laufe dieses Buches betrachtete Beispiel „Schiffe versenken") verdeutlicht wird, wie Beans verwendet werden.

• Eine Java-Klasse muss mit einem Null-Konstruktor versehen werden, damit sie korrekt instantiiert werden kann.
• Ein visuelles Bean sollte seine Eigenschaften möglichst von der Klasse java.awt.Component oder von ihrer Subklasse Canvas erben. Diese Klassen bieten die Grundfunktionalität, die ein Bean einsetzen kann, u. a. das Event-Modell, die Internationalisierung oder auch Fonts.
• Die direkte Typumwandlung (Casting) bzw. die Verwendung des instanceof-Operators sollten nach Möglichkeit vermieden werden. Statt dessen sollten die Methoden Beans.isInstanceOf und Beans.getInstanceOf benutzt werden, um Typumwandlungen von Beans vorzunehmen.
• In Beans sollten Namenskonventionen für Events eingesetzt werden. Beans, die Events auslösen, sollten die Methoden addListenerEventTyp und removeListenerEventType beinhalten. Klassen, die sich für Events registrieren, sollten die Klasse EventListenerType implementieren. Eine Event-Klasse sollte die Endung Event verwenden.
• In Beans sollten Namenskonventionen für Eigenschaften eingesetzt werden, vor allem Getter- und Setter-Methoden. Diese Methoden werden direkt von der Beans-Introspektion erkannt.
• Für die Kommunikation von Beans werden Standardadapter benutzt.
• Beans, die persistent sein müssen, implementieren eines der Interfaces Serialization oder Externalization.
• Einfache Datentypen sind standardmäßig serialisiert. Alle Daten, die nicht gespeichert werden sollen, müssen mit dem Schlüsselwort transient ausgezeichnet werden.
• Event-Listener von Events, die von Beans generiert werden, dürfen nicht persistent sein. Aus diesem Grund sollte der Vektor-Listener als transient deklariert werden, wodurch Event-Listener nicht automatisch serialisiert werden.
• Zu jedem Bean gehört eine BeanInfo-Klasse, die durch die Introspektionsklasse inspiziert wird. Die BeanInfo-Klasse enthält u. a. einen Verweis auf das Icon, das ein Bean repräsentiert.
• Die Namen von Setter- und Getter-Methoden für Eigenschaften sollen eindeutig sein. Auch wenn Eigenschaften verschiedene Datentypen haben, ist es nicht zu empfehlen, die gleichen Methodennamen zu verwenden. Die Introspektion einer Entwicklungsumgebung kann zwei Setter- bzw. Getter-Methoden nicht erkennen, wenn diese denselben Namen aufweisen.
• Customizer sollten ihre Eigenschaften von der Klasse java.awt.Component oder von deren Subklasse Canvas erben, damit sie innerhalb eines AWT-Dialogs oder Panels instantiiert werden können.
• Customizer müssen, wie JavaBeans, einen Null-Konstruktor beinhalten.
• Ressourcen, die übersetzt werden sollen, sollten nicht im Quellcode enthalten sein, damit sie getrennt übersetzt werden können, ohne stets den gesamten Code neu kompilieren zu müssen.
• Quelldateien für internationalisierte Beans, bspw. Text-, Bild- und Audiodateien sollten Teil einer JAR-Datei sein, damit sie durch Dritte übersetzt werden können und das Bean in der Folge in einer anderen Umgebung ausgeführt werden kann.
• Bei internationalisierten Beans sollten die Icons, die Beans repräsentieren, keinen kulturabhängigen Text aufweisen.
• JAR-Dateien sollten dazu verwendet werden, um Beans abzuspeichern und über Netzwerke zu verteilen. Eine Manifest-Datei muss hierbei in jedem JAR-Archiv vorhanden sein.
• Beim Packen eines Beans, das durch die Kommandozeileneingabe gesteuert wird, kann die Option 0 dazu verwendet werden, dass die Daten nicht komprimiert werden, da einige Entwicklungsumgebungen komprimierte JAR-Dateien nicht lesen können.