WikiDer > JavaBeans

Java-Plattformportal

JavaBeans (auch gekürzt zu Bohnen) sind eine Form von komponentenbasierten Softwaretechnologie definiert innerhalb der Java-Plattform. Eine JavaBean ist eine Softwarekomponente, die bestimmten Konventionen folgt und somit in ein API. Indem diese Konventionen befolgt und die Möglichkeiten der JavaBeans-API genutzt werden, werden JavaBeans zu wiederverwendbaren Komponenten, die dort konfiguriert werden können, wo sie letztendlich bereitgestellt, mit Softwaretools manipuliert und mit anderen Teilen verknüpft werden. .

Aufgrund ihres Namens werden JavaBeans oft verwechselt mit Enterprise JavaBeans. Obwohl diese beiden Komponententechnologien konzeptionell verwandt sind, sind sie deutlich voneinander getrennt.

JavaBeans-Definition

In der offiziellen API-Spezifikation sind JavaBeans definiert als

Eine Java Bean ist eine wiederverwendbare Softwarekomponente, die mit einem Entwicklungstool visuell bearbeitet werden kann.

Direkt aus dieser Definition folgt die Notwendigkeit für die meisten Eigenschaften, die JavaBeans laut Spezifikation haben:

JavaBeans sind Komponenten

Eine JavaBean ist eine separate Software, eine definierte und vollständige Funktionalität, die in einem einzigen Paket verpackt ist.

JavaBeans sind wiederverwendbar

Ein JavaBean-Muss generisch sind in seiner Struktur. Es ist nicht beabsichtigt, dass eine Software, die nur an einer Stelle und auf eine Weise verwendet werden kann, in JavaBean verarbeitet wird. Gleichzeitig bedeutet dies, dass eine JavaBean Konfigurationsmöglichkeiten bieten muss, um ihre Funktionsweise an die jeweilige Einsatzsituation der Bean anzupassen – natürlich ohne den Code der Bean anpassen zu müssen.

JavaBeans können mit einem Entwicklertool visuell bearbeitet werden

Eine JavaBean muss allgemein konfigurierbar sein. Das Vorhandensein einer allgemeinen Konfigurationsmethode ermöglicht es Entwicklungstools, diese Konfiguration zu berücksichtigen, ohne genau zu wissen, wie ein bestimmtes Bean funktioniert.

Eigenschaften einer JavaBean

Die API-Spezifikation besagt, dass eine JavaBean alle ihre konfigurierbaren Eigenschaften benennen muss: die sogenannten Eigenschaften einer Java Bean.

Eigenschaften können primitive Typen sein oder Klassen. Sie können auch indiziert werden, was die Idee repräsentiert, dass eine Eigenschaft aus mehreren Teilen in einer bestimmten Reihenfolge besteht. Eine Eigenschaft muss jedoch nicht unbedingt ein Feld in einer Klasse sein: Sie kann auch ein Wert sein, der bei Bedarf kompiliert wird. Um diese Unterscheidung zu ermöglichen und vor Benutzern einer JavaBean verborgen zu halten, legt die Spezifikation die Vereinbarung fest, dass auf eine Eigenschaft einer Bean nicht direkt zugegriffen werden soll, sondern mit geeigneten Methoden gelesen und verändert wird: die so- namens Getter und Setter Methoden. Für Werkzeuge gilt die harte Konvention für die Namen von Gettern und Settern für eine gegebene Eigenschaft: wenn eine Bean eine Eigenschaft ist Stütze Besitz, dann gibt es einen Getter getProp und ein Setter setProp.

Ein Bean definiert seine eigenen Getter und Setter und die zugehörige Logik. Da eine Bean genau wissen muss, wie eine Eigenschaft funktioniert, kann die Bean auch entscheiden, dass bestimmte Werte für eine Eigenschaft nicht erlaubt sind: Die Bean kann mittels einer PropertyVetoException gegen eine angeforderte Änderung einer Eigenschaft ein Veto einlegen.

Zusätzlich zum System der Getter und Setter können JavaBeans umfangreiche Informationen über ihre Eigenschaften veröffentlichen, indem sie BeanInfo- und BeanDescriptor-Klassen bei JavaBeans registrieren. Letztere liefert allgemeine Informationen über die Bean (Name, Anzeigename, beliebige Icons), erstere ist eine optionale Klasse, die tiefer in die einzelnen Eigenschaften eingeht.

Ereignisse in JavaBeans

Die meisten Benutzer von Beans (anderer Software) finden es interessant, nicht nur die Eigenschaften von Beans zu lesen und zu ändern, sondern auch informiert zu werden, wenn etwas passiert, das den Wert einer Eigenschaft ändert. Die API-Spezifikation definiert hierfür ein Ereignismodell.

Innerhalb dieses Ereignismodells können Softwareteile einer Bean mitteilen, dass sie über Änderungen der Eigenschaften dieser Bean benachrichtigt werden möchten. Es obliegt der Bean, sich darum zu kümmern, möglicherweise mittels einer Hilfsklasse, die die API dafür definiert. Die Bean kann auch Drittanbieter-Software erlauben, eine bestimmte Eigenschaft und nicht alle zu verfolgen. Um all dies zu ermöglichen, gibt die API-Spezifikation an, dass es PropertyChangeEvents und auch PropertyChangeListeners gibt.

Aufgrund dieses Mechanismus kann eine Bean auch ankündigen, wenn sie einer Änderung ein Veto eingelegt hat. Dazu dienen die sogenannten VetoableChangeListener.

JavaBeans Lagerung und Versand

JavaBeans soll es ihnen ermöglichen, ihren internen Zustand zu speichern und als Komponente ferngesteuert zu werden. JavaBeans sollen daher serialisierbar sein.

Eigenverantwortung des Programmierers

Die JavaBeans-Komponententechnologie beruht stark auf der Eigenverantwortung des Programmierers. Ziel der Spezifikation ist es, eine möglichst offene und flexible API zu schaffen, die Entwickler und Nutzer von Komponenten möglichst wenig einschränkt.

Es bleibt also dem Programmierer selbst überlassen, ob eine Komponente eine gute JavaBean ist, die allen Konventionen folgt. Deskriptoren und Infos sind Ihre Wahl, es gibt kaum Schnittstellen, die Bean-Klassen einen gewissen Stempel aufdrücken oder diese unterstützen. Ein Programmierer muss auch sicherstellen, dass eine Bean richtig funktioniert: Unterstützung für Fernbedienung, Multithreading und dergleichen liegen in der Verantwortung des Programmierers.

Verwenden einer JavaBean

Die JavaBeans-Spezifikation legt großen Wert auf die Idee einer JavaBean als visuelle Komponente (obwohl sie nicht erforderlich ist). Sowohl die Idee, dass eine JavaBean über ein visuelles Tool konfiguriert wird, als auch selbst eine Schnittstelle bietet, ist stark im Standard verwoben. In dieser Hinsicht ist klar, dass JavaBeans ein Standard aus der Zeit sind, als der Fokus der Java-Plattform viel mehr auf Desktop-Anwendungen lag als heute.

Die Idee hinter der Spezifikation ist, dass eine JavaBean letztendlich eine Komponente ist, die direkt in andere Software gesteckt werden kann. Es handelt sich um eine eigenständige Funktionalität, die verwendet wird und nur konfiguriert werden muss (mit oder ohne eigene Schnittstelle in einem Grafikprogramm). Der Standard stellt JavaBeans als Komponenten jeder Größenordnung bereit, von einem einfachen Widget wie ein Knopf zum Vervollständigen Kalkulationstabelle die selbst andere JavaBeans verwendet (über die Konfiguration). Die Norm schlägt auch eine Brücke zu anderen Komponentenformen wie z COM und ActiveX Komponenten (aber definiert nicht, wie diese Brücke funktionieren soll).

Darüber hinaus ist ein wichtiger Punkt der Spezifikation, dass eine JavaBean durch visuelle Tools konfigurierbar sein muss. Praktisch jede Klasse und jedes Interface rund um die JavaBeans-Spezifikation konzentriert sich darauf: Klassen und Interfaces, um zu definieren, was die Eigenschaften einer Bean sind, was sie darstellen und wie sie angezeigt werden sollen. Klassen, um Sie zu informieren, wenn sie sich ändern. Klassen, um diese anderen Klassen und Schnittstellen zum Konfigurieren von Beans zu verwenden.

JavaBeans-Komponenten in der Praxis

JavaBeans, egal wie man es betrachtet, sind nicht was geworden Sonne Mikrosysteme erhofft hatte. Mit der Einführung der API in Version 1.1 der Java-Plattform hatte Sun gehofft, einen Komponentenmarkt für Java ähnlich dem COM-, COM- und ActiveX-Markt von Java anzukurbeln. Microsoft. Das hat nicht funktioniert.

Dafür gibt es eine Reihe von Gründen. Zunächst einmal wurde die Spezifikation von Sun zu einer Zeit entworfen, als Java noch zu neu war, um bei den kommerziellen Playern wirklich Fuß zu fassen. Zweitens hatte Java alle möglichen Probleme, die die Plattform weniger attraktiv machten (schlechte Leistungsbilanz, rechtliche Probleme zwischen Sun und Microsoft).

Außerdem half es nicht, dass Sun gleichzeitig ziemlich vage und undurchsichtig mit allem möglichen sehr ähnlichen Dingen arbeitete, so dass die Positionierung bestimmter Techniken und Technologien nicht ganz klar war. JavaBeans hatte einen schlechten Start und dann tauchte Sun mit auf Servlets und vor allem mit Enterprise JavaBeans. Angesichts der Tatsache, dass eine JavaBean (im Prinzip) kaum mehr ist als eine "normale" Klasse (oder eine Gruppe von normalen Klassen) und einige Konventionen, wurde plötzlich sehr unklar, was der Vorteil gegenüber EJBs und all den damit verbundenen Einrichtungen war. Außerdem verlagerte sich die Aufmerksamkeit plötzlich auf Webanwendungen und J2EE und der Fokus auf den Desktop ließ nach – und damit JavaBeans, mit starker Betonung der Grafik (zu Recht oder zu Unrecht).

Dennoch haben JavaBeans und ihre Einrichtungen einen enormen Einfluss auf die Java-Plattform gehabt, und zwar in einer Weise, die Sun nie vorhersehen konnte. Nämlich wegen der Idee einer festen Vereinbarung über die Adressierung von Eigenschaften über Getter und Setter. Die ursprüngliche API-Spezifikation sah bereits die Verwendung von Reflektion vor, um die Eigenschaften einer JavaBean festzulegen, stützte sich jedoch stark auf alle Arten von Beschreibungsklassen, um sie nutzbar zu machen. Seitdem sind jedoch viele interessante APIs, Tools und ganze Frameworks entstanden, die die Beschreibung für sich belassen und komplett auf Überlegung zurückgreifen, um Eigenschaften nach dem Getter- und Setter-Prinzip zu setzen. Zu den interessanteren Frameworks, die stark darauf angewiesen sind, gehören Überwintern, iBati und springen, neben zum Beispiel JMX.