2007-11-29

JavaBeans (Teil 1)

Mit diesem Eintrag möchte ich eine lose Serie von Artikeln über JavaBeans beginnen. JavaBeans, oder kurz: Beans, sind (mit dem Ziel der Wiederverwendung entwickelte) Softwarekomponenten. Die Idee ist, kleine Einheiten (Komponenten) mit einem geeigneten Werkzeug zu einem größeren Ganzen (Applets und Anwendungen) zu kombinieren. Natürlich sind Komponenten keine Java-Erfindung. Andere Plattformen haben ihre eigene Komponentenarchitektur hervorgebracht. Ein äußerst erfolgreiches Beispiel ist das Component Object Model von Microsoft, das über viele Jahre der Standard für die Kommunikation über Anwendungsgrenzen hinweg unter Windows war, und selbst jetzt noch häufiger eingesetzt wird, als es sich der Betriebssystemhersteller vermutlich wünscht.
JavaBeans ist also eine Komponententechnologie für Java. Sie wird in praktisch allen modernen Anwendungen eingesetzt, ohne dass sich die Entwickler besonders darum kümmern. Ein Beispiel hierfür ist der selbstverständliche Umgang mit Gettern und Settern, aber auch das Auswählen von Swing-Komponenten aus den Paletten eines visuellen Editors. In den folgenden Teilen dieser kleinen Serie möchte ich Ihnen einige Einblicke in die Funktionsweise und die Implementierung von JavaBeans geben. Beispielsweise zeige ich Ihnen, wie Sie eigene visuelle Komponenten entwickeln und in die Palette eines GUI-Builders integrieren.
All dies möchte ich am Beispiel einer kleinen Komponente demonstrieren, die Sie im Screenshot etwas weiter oben sehen. Haben Sie eine Idee, um was es sich hierbei handelt?

Update 25.12.14 Screenshot entfernt

2007-11-28

Vereinfachte Verteilung mit One-JAR

Es ist allgemein bekannt, dass man auf sehr vielen Plattformen eine Java-Anwendung durch Doppelklick auf die zugehörige .jar-Datei starten kann. Das Pendant für die Kommandozeile lautet java -jar archiv.jar. Damit dies funktioniert, muss das Archiv die Textdatei /META-INF/MANIFEST.MF enthalten. Eine ihrer Zeilen lautet
Main-Class: com.domain.package.Main
Dem Attribut Main-Class wird also ein voll qualifizierter Klassenname zugewisen. Diese Klasse enthält die wohlbekannte main()-Methode, also den Einstiegspunkt in das Programm. Zusätzliche Bibliotheken, die die Anwendung benötigt, können ebenfalls in das oben genannte Manifest eingetragen werden. Hierfür wird das Attribut Class-Path verwendet. Es enthält eine durch Leerzeichen getrennte Liste von (das ist wahrscheinlich weniger bekannt!) URLs (Verzeichnisse und Archive), die nach Klassen durchsucht werden sollen. Diese dürfen sich aber nicht innerhalb des Hauptarchivs befinden. Der Versuch, .jar-Archive zu schachteln, führt also zu nicht funktionsfähigen Programmen.
Man kann natürlich die Frage stellen, ob das Schachteln von Archiven überhaupt nötig ist. Web Start-Anwendungen beispielsweise profitieren eher von der Aufteilung in unterschiedliche .jars, weil Basisbibliotheken u. U. schon einmal herunter geladen wurden und damit schon zur Verfügung stehen. Praktisch könnte eine einzelne, leicht handhabbare Datei hingegen sein, wenn die Anwendung beispielsweise auf einem USB-Stick eingesetzt werden soll. Denn beim Kopieren besteht die Gefahr, eine benötigte Bibliothek zu übersehen und zu vergessen. Dies würde dazu führen, dass Sie das Programm nicht verwenden können.
One-JAR von Simon Tuffs kann Programme und ihre Bibliotheken zu einem einzigen Archiv zusammen fassen. Das open source-Projekt setzt hierzu auf einen eigenen ClassLoader, der das Laden von Klassen und Ressourcen aus verschachtelten Archiven beherrscht. Damit der neue Klassenlader greift, muss das Manifest einer Anwendung so abgeändert werden, dass das Main-Class-Attribut auf eine von One-JAR zur Verfügung gestellte Bootstrap-Klasse zeigt. Ferner werden Bibliotheken in einem eigenen lib-Verzeichnis erwartet. Das Archiv mit der ursprünglichen Hauptklassen muss unter main abgelegt werden. Um dem Programmierer die Aufgabe so leicht wie möglich zu machen, stellt Simon Tuffs auch eine Ant-Integration zur Verfügung