Das Java Komponentenmodell:
Java Beans

Autor: Axel Faltin
Matrikelnr.: wi7713

INHALT

• Was sind Komponenten?
• Warum Komponenten? & Warum Java?
• Welche Konzepte kommen zum Einsatz?
• Programmbeispiele/Beanbox

Das Java Komponentenmodell - Java Beans

1. Was sind Komponenten? Komponenten sind ...
   • selbstenthaltene
   • wiederverwendbare
   • meist visuell manipulierbare
     
     Softwareteile, die mit Hilfe von sogenannnte Buildern zu neuen Komponenten, Programmen, Applets usw. zusammengesetzt werden koennen.

2. Warum Komponenten?
   • Modularitaet, Kapselung der Logig
   • gute Ueberschaubarkeit fuer grosse Projekte
   • Wiederverwendbarkeit
   • Einfachheit durch Visualisierung
   das heisst Softwarekomponenten sind ...
   • einfacher zu nutzen und leichter zu warten

   $$ Preiswert in der Entwicklung

3. Was machen Java Beans aus?
   • komplett in Java $$ alle Vorteile & Nachteile von Java
     • Portabilitaet, ``write once run everywhere'' $$
     • Sicherheit $$, Robustheit $$
     • Objektorientierung $$
     • Wiederverwendbarkeit $$
     • Geschwindigkeit $\downarrow$
   • leichtgewichte, ein Bean braucht nicht viel um ein Bean zu sein

4. Welche Konzepte kommen zum Einsatz?
   1. Java Ereignis/Event Modell
   2. Eigenschaften/Properties
   3. Introspection
   4. Benutzerhilfe-Anpassung/Customization
   5. Persitenz/Persistence
   6. Packaging/Archivierung in Jar

(a) Java Ereignis/Event Modell

• Ereignisse koennen, muessen aber nicht auftreten
• Ereignisse dienen der entkoppelten Kommunikation zwischen Objekten
• Ereignisse werden von java.util.EventObject abgeleitet werden
• Das Ereignisobjekt enthaelt alle Informationen zum Ereignis, z.B. Mauskoordinaten bei Mausereignis
• Ereignisquellen stellen Registriermechanismen fuer Zuhoerer zur Verfuegung und pflegen somit eine Liste von Zuhoerern
  • add<ListenerType>(<ListenerType> l)
  • remove<ListenerType>(<ListenerType> l)
  • Auf diese Weise wird von der Quelle, eine vom Zuhoerer implementierte Methode, aufgerufen und der Zuhoerer kann das Ereignis verarbeiten.
  • Zuhoerer muessen java.util.EventListener implementieren

(b) Eigenschaften/Properties

• Eigenschaften sind benannte Attribute oder Charakteristika von Objekten bzw. Beans
• sie definieren Zustand und Verhalten eines Beans
• sie werden ueber ihren Namen Referenziert
• sie gehoeren im Regelfall zum Persistenten Teil des Beans
• sie lassen sich mit visuellen Editoren manipulieren

Zugriff auf Eigenschaften

• Zugriffsmethoden:

     public void set<PropertyName>(<PropertyType> value);
     public <PropertyType> get<PropertyName>();

• fuer Boolsche Eigenschaften ist folgenden vorgesehen:

     public boolean is<PropertyName>();

• sie koennen readonly, read/write oder writeonly deklariert werden

Indexierte Eigenschaften/indexed properties

• eine Eigenschaft besteht aus einem ganzen Array von Eigenschaften
• der Zugriff erfolgt per Index
• man kein ein Element oder ganze Sammlungen abfragen

• es gelten folgende Signaturen:

     public void set<PropertyName>(<PropertyType>[] value);
     public <PropertyType>[] get<PropertyName>();
     public void set<PropertyName>(int index, <PropertyType> value);
     public <PropertyType> get<PropertyName>(int index);

• man sollte hier das Ausloesen einer ArrayIndexOutOfBoundsException einplanen

Gebundene Eigenschaften/bound properties

• gebundene Eigenschaften implementieren einen Benachrichtigungsdienst fuer Aenderungen
• Listenerverwaltung:

    public void addPropertyChangeListener(PropertyChangeListener p);
    public void removePropertyChangeListener(PropertyChangeListener p);

• propertyChange() wird vom PropertyChangeListener implementiert
• die Signatur sind wie folgt aus:

  public synchronized void addPropertyChangeListener(
                           PropertyChangeListener listener);
  public synchronized void removePropertyChangeListener(
                           PropertyChangeListener listener);
  public void firePropertyChange(PropertyChangeEvent evt);

• jene wird zur Hilfe von java.beans.PropertyChangeSupport implementiert
• Beispiel Temperature.java

Eingeschraenke Eigenschaften/constrained properties

• sie erlauben es einem externen Programmteil eine Aenderung abzulehnen
• d.h. der neue Wert einer Eigenschaft wird extern auf Gueltigkeit geprueft
• jene exteren werden als Listener verwaltet und ein Aenderungsereignis ausgeloest
• die Signature wird durch ein Veto erweitert:

     public <PropertyType> get<PropertyName>();
     public void set<PropertyName>(<PropertyType> value)
                 throws java.beans.PropertyVetoException;

• Objekte die eine Gueltigkeitspruefung durchfuehren wollen muessen VetoableChangeListener implementieren
• Beans die eingeschraenkte Eigenschaften anbieten muessen Registrierungsmethoden zur Verfuegung stellen:

     public void addVetoableChangeListener(VetoableChangeListener p);
     public void removeVetoableChangeListener(VetoableChangeListener p);

• bei Ablehnung wird eine PropertyVetoException ausgeloest
• auch hier gibt es eine Hilfsimplementation VetoableChangeSupport
• Beispiel Constrainer.java, Thermometer.java

(c) Introspection

• Um in einem Builder benutzt werden zu koennen muessen Eigenschaften, Methoden und Ereignisse offengelegt werden
• Dazu gibt es zwei Konzepte
  1. Reflexion
     • mit hilfe von Namenskonventionen koennen Builder Muster erkennen und Editoren generieren
     • dazu wird der Reflexionsmechanismus von Java eingesetzt, java.lang.reflect)
  2. BeanInfo Schnittstelle
     • diese Schnittstelle stellt eine Beschreibung zu einem Bean zur Verfuegung
     • Namenskonvetion fuer BeanInfo: <zu beschreibenes Bean>BeanInfo
     • Leistungmerkmale werden mit einem FeatureDescriptor beschrieben, die Basisklasse enthaelt bereits info zum Namen und Displaynamen der Klasse.
     • Nachteil: Trennung von Bean und Beschreibung in zwei Objekte (Wartungsintensiv)
     • Ein Teil der BeanInfo Schnittstelle ist im folgenden beschrieben:
       • BeanDescriptor getBeanDescriptor() liefert Displaynamen und ggf. Verbindung zu einem Customizer
       • PropertyDescriptor[] getPropertyDescriptors() beschreibt die oeffentlichen Eigenschaften, get/set Methoden und ggf Spezielle Editoren, siehe Beispiel Storage.java (spaeter)
       • MethodDescriptor getMethodDescriptor() beschreibt die oeffentlichen Methoden des Beans mit Parameter
       • EventDescriptor getEventSetDescriptor() beschreibt die Ereignisse, die vom Bean ausgeloest werden koennen (Quellklasse, Eventname, Listenertype und Listenermethodenname)
       • Image getIcon() liefert ein Icon fuer die Anzeige in einer Palette
       • BeanInfo[] getAdditionalBeanInfo() liefert weitere Beschreibungen fuer Bean, wenn es z.B. eine Hierachie gibt
     • eine Hilfsimplementation kann hier viel Arbeit ersparen: java.beans.SimpleBeanInfo
• Beispiel StorageBeanInfo.java

(d) Benutzerhilfe-Anpassung/Customization

• Um die Features von Beans visuell anzupassen werden sogenannte Propertysheets benutzt.
• diese sheets werden mit Eigenschaftseditoren implementiert
• will man dem Benutzer eine spezielle Moeglichkeit der manipulation gewaehren muss man die java.beans.PropertyEditor Schnittstelle implementiren
• diese Schnittstelle definiert grundsaetzliche Funktioen, z.B. Zugriff auf Textrepresentationen von Werten
• die Verbindung zwischen Editor und Eigenschaft wird per BeanInfo hergestellt
• man legt die Klasse mit PropertyDescriptor.setPropertyEditorClass (Class propertyEditorClass) fest
• Siehe Beispiel ModeEditor.java

Customizer

• Customizer sind nun Anpassungselemente die ganze Beans nicht nur eine Eigenschaft anpassen sollen
• sie sind nicht auf die oeffentlichen Methoden beschraenkt, da sie eine Referenz auf das Bean besitzen
• sie kommen zum Einsatz, wenn Bean sehr Komplex werden
• Kein Customizer ohne BeanInfo, da die Verbindung per BeanInfo gemacht wird
• Customizer haben alle Moeglichkeiten einer GUI, muessen nur java.beans.Customizer und java.awt.Component implementieren.
• Customizer enthaelt nur die Listenerverwaltung und eine Methode void setObject(Object bean) um eine Referenz auf das Bean zu haben.

(e) Persitenz/Persistence

• Komponenten pflegen ueber die Programmlogik hinaus Informationen, die Erscheinung und Verhalten der Komponente beschreiben
• viele sind Eigenschaften wie z.B. Schriftart, oder Farbe der Komponente
• Eigenschaften aendern sich wahrend des Programmlaufes und man moechte jene persistent zu machen - sie speichern
• Java Beans bedienen sich dazu der Java Objekt Serialisierung (java.io.Serialization)
• Beispiel Storage.java
• Versionproblematik, Kompatibilitaet
  • wird eine Klasse Veraendert, wird die JVM eine InvalidClassException Ausloesen auch wenn die Aenderungen Kompaible waren
  • Kompatible Aenderungen sind die die keine Eigenschaften veraendern sondern ausschliesslich Methoden
  • damit die JVM keinen Fehler melder verpasst man allen Kompatiblen Klassen einen Stream Unique Identifier (SUID)
  • Mit Hilfe des Programmes serialver lassen sich solche SUID erzeugen, welche dann mit Hilfe einer Konstante (z.b. static final long serialVersionUID = 8984554447612061263L;) in den kompatiblen Quellcode eingesetzt werden.
• Objekte, die die Schnittstelle java.io.Externalization implementieren koennen ebenfalls persistent gespeichert und wieder herhgestellt werden.
• die JVM schaut erst nach der Schnittstelle Serializable and anschliessend nach Externalizable
• Externalizable Klassen muessen sich komplett um die Abarbeitung der Speicherung kuemmern und ggf. auch selber die Klassenhierachie abarbeiten.
• de/serialisiert wird mit readExternal()/writeExternal()
• es gibt hier anders als bei Serializable keine default Routinen
• Instanzierung von serialisierten Beans erfolgen per instantiate() der Klasse java.beans.Beans
• diese statische Methode braucht einen Klassenlader (bleibt meisst null) und einen String welcher das Bean spezifiziert
• gibt es eine Datei die den gleichen Namen wie das Bean (Endung .ser), wird es geladen und der default Konstruktor wird aufgerufen.

(f)Packaging/Archivierung in Jar

• Java Beans werden gepackt und verteilt in JAR Files (im Zip-format)
• alle Dateien die zu einer Bean gehören, wie z.B. die Klassen-Dateien, serialisierte Objekte, Bilder, Help-Files zusammen ausgeliefern werden
• der Benutzer bekommt eine Datei
• das jar-Archiv enthaelt eine Manifest Datei, die den Inhalt naeher beschreibt.
• es koennen auch mehrere Bean in einer Manifest Datei beschrieben werden
• Siehe Storage-Bean fuer Beispiel Manifest
• erzeugen eines Jar Archives: z.B ein Bean UltraWurst

     $ jar cfm UltraWurstBean.jar UltraWurst.mf UltraWurst.class

 
• Über dieses Dokument ...