Jürgen Petri

NetBeans RCP

O’Reilly ®

- Behandelt NetBeans 6- Modulare Entwicklung- FormBuilder Matisse- Fensterverwaltung- Nodes, DataObjects, Wizards ...

EntwicklerheftDas

NetBeans RCPDas Entwicklerheft

Jürgen Petri

Beijing • Cambridge • Farnham • Köln • Paris • Sebastopol • Taipei • Tokyo

Die Informationen in diesem Buch wurden mit größter Sorgfalt erarbeitet. Dennoch können Feh-ler nicht vollständig ausgeschlossen werden. Verlag, Autoren und Übersetzer übernehmen keine juristische Verantwortung oder irgendeine Haftung für eventuell verbliebene Fehler und deren Folgen.Alle Warennamen werden ohne Gewährleistung der freien Verwendbarkeit benutzt und sind möglicherweise eingetragene Warenzeichen. Der Verlag richtet sich im Wesentlichen nach den Schreibweisen der Hersteller. Das Werk einschließlich aller seiner Teile ist urheberrechtlich ge-schützt. Alle Rechte vorbehalten einschließlich der Vervielfältigung, Übersetzung, Mikroverfil-mung sowie Einspeicherung und Verarbeitung in elektronischen Systemen.

Kommentare und Fragen können Sie gerne an uns richten:O’Reilly VerlagBalthasarstr. 8150670 KölnTel.: 0221/9731600Fax: 0221/9731608E-Mail: kommentar@oreilly.de

Copyright der deutschen Ausgabe:© 2008 by O’Reilly Verlag GmbH & Co. KG1. Auflage 2008

Java™ und alle auf Java basierenden Warenzeichen und Logos sind in den USA und in allen an-deren Ländern Warenzeichen oder registrierte Warenzeichen von Sun Microsystems, Inc.

O’Reilly Media, Inc. und der O’Reilly Verlag GmbH & Co. KG sind von Sun Microsystems Inc. un-abhängig.

»Entwicklerhefte« und »A Developer’s Notebook Series« und darauf basierende Warenzeichen und Logos sind Warenzeichen von O’Reilly Media und dürfen nicht ohne schriftliche Genehmigung verwendet werden.

Bibliografische Information Der Deutschen BibliothekDie Deutsche Bibliothek verzeichnet diese Publikation in der Deutschen Nationalbibliografie; detaillierte bibliografische Daten sind im Internet über http://dnb.ddb.de abrufbar.

Lektorat: Christine Haite, KölnFachgutachter: Markus Jais, München & Jens Boß, MünsterKorrektorat: Petra Bromand, DüsseldorfSatz: G&U Technische Dokumentation GmbH, Flensburg; www.gundu.comUmschlaggestaltung: Edie Freedman, Boston & Michael Oreal, KölnProduktion: Karin Driesen, KölnBelichtung, Druck und buchbinderische Verarbeitung: Druckerei Kösel, Krugzell; www.koeselbuch.de

ISBN-13 978-3-89721-724-9Dieses Buch ist auf 100% chlorfrei gebleichtem Papier gedruckt.

III

Inhalt

Über die Entwicklerhefte . . . . . . . . . . . . . . . . . . . . . . . . VII

Über dieses Buch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . XI

Kapitel 1: Module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1Modulare Entwicklung 1

Eigenschaften eines Moduls 2

Anlage eines Moduls 4

Abhängigkeiten verwalten 7

Versionierung 9

Installation von Modulen 11

Exkurs: Die Beispielapplikation 13

Kapitel 2: Formulare . . . . . . . . . . . . . . . . . . . . . . . . . . . 19Form Builder 19

Anlage eines Formulars 21

Event-Handling 28

Modifikation von generiertem Code 30

Kapitel 3: Die Window System API . . . . . . . . . . . . . . . . . 33Fenster erzeugen 34

Lebenszyklus verwalten 43

Die Positionierung der Fenster 47

Eigene Docking Modes erzeugen 52

Fenster gruppieren 56

Persistierung des Layouts 58

IV Inhalt

Kapitel 4: Die Lookup API . . . . . . . . . . . . . . . . . . . . . . . 65Services finden 65

Erweiterungspunkte 69

Lose gekoppelte Kommunikation zwischen Komponenten 73

Dynamisierung und Benachrichtigung 80

ProxyLookups 87

ActionsGlobalContext 89

Kapitel 5: Die Actions API . . . . . . . . . . . . . . . . . . . . . . . 97Globale Actions 97

Einfügen in Menüs, Toolbars etc. 104

Keybindings 106

Presenter 107

Kapitel 6: Die Nodes API und die Explorer API . . . . . . . . 111Nodes 112

ExplorerViews 119

Schlüsselbasierte Node-Hierarchien 125

Austauschen von Views 133

Langläufiges Ermitteln von Kindelementen 135

Kontextsensitive Aktionen 140

Nodes dekorieren 153

PropertySheets 159

Inplace-Property-Editoren 163

Kapitel 7: Die File System API . . . . . . . . . . . . . . . . . . . 167SystemFileSystem 168

Zugriff auf das lokale Dateisystem 168

Zusätzliche Attribute 173

Überwachung 174

Kapitel 8: Die Datasystems API . . . . . . . . . . . . . . . . . . . 175Unterstützung neuer Dateitypen 175

Zustandsabhängige Fähigkeiten 190

Inhalt V

Kapitel 9: Die Dialogs API . . . . . . . . . . . . . . . . . . . . . . 199Benachrichtigungen 199

Standarddialoge 201

Eigene Dialoge 203

Mehrseitige Dialoge 208

Kapitel 10: Einstellungen . . . . . . . . . . . . . . . . . . . . . . . 227Integration in das Options-Panel 227

Kapitel 11: Hilfe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 235Eigene HelpSets erzeugen 235

Entfernen der Standardhilfe 244

Kapitel 12: Branding . . . . . . . . . . . . . . . . . . . . . . . . . . 247Selbständige Applikation 247

Splash-Screen 249

Kapitel 13: Distribution & Updates . . . . . . . . . . . . . . . . 251Distribution 251

Installer 253

Online-Updates 257

Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 263

VII

Über die Entwicklerhefte

So, Sie haben das Buch also gekauft. Cool. Natürlich fragen Sie sich,warum die Bücher dieser Reihe solche merkwürdigen Einbände haben,die eher an ein Notizbuch erinnern. Ist das hier wirklich von O’Reilly? Wosind die Tiere? Und ist es denn wirklich nötig, eine weitere Buchreiheherauszubringen? Könnte dies nicht auch einfach ein »Kochbuch« sein?Wie wär’s mit einem »Nutshell«-Band oder mit einem »Hacks«-Buch? Aufdiese Fragen gibt es eine kurze Antwort: Ein Entwicklerheft ist nichtsdavon – die Idee, die diesen Büchern zugrunde liegt, erschien uns tat-sächlich so wichtig, dass wir mit einem völlig neuen Look & Feel heraus-gekommen sind, komplett mit eigenem Umschlag, eigenen Schriften undsogar mit Randnotizen. Dies alles ist das Ergebnis unserer Bemühungen,Ihnen ein Buch an die Hand zu geben, das Ihnen bei der praktischenArbeit weiterhilft.

Die neunziger Jahre waren dadurch gekennzeichnet, dass alle alles ler-nen wollten. (Warum auch nicht? Damals hatten wir alle sechsstelligeGehälter bei Dotcom-Firmen.) Das neue Jahrhundert dagegen ist durchdie Fülle an Informationen geprägt. Niemand hat noch die Zeit (oder dasGeld), 600-seitige Wälzer durchzulesen und dabei 200 Dinge zu lernen,von denen aber vielleicht nur vier auf die momentane Tätigkeit anwend-bar sind. Wäre es nicht viel besser, sich neben einen jener Super-Pro-grammierer zu setzen und ihm über die Schulter zu schauen? Jemandenzu fragen, der in diesen Dingen zu Hause ist, wie er oder sie diese eineverzwickte Aufgabe erledigt oder jenes Threading-Problem bei der Arbeitmit Piped-Streams vermieden hat? Bücher stehen in dem Ruf, dieses spe-zielle Bedürfnis nicht befriedigen zu können – sie können informieren,aber die Gedankengänge eines Programmierers werden letztendlich füretwas gehalten, das man nicht wirklich auf einem Blatt Papier abbildenkann.

VIII Über die Entwicklerhefte

Diese Buchserie behauptet, dass diese Annahme falsch ist – und wir wol-len das auch beweisen.

Ein Entwicklerheft ist genau das, was der Name sagt: die Bemerkungenund Notizen, die ein Alpha-Geek im Geiste macht, während er mit einerneuen Sprache, einer neuen API oder einem neuen Projekt arbeitet.Dabei handelt es sich vor allem um geradlinigen Programmcode, mit demman Probleme lösen kann, befreit von den seitenlangen Kommentaren,die eher eine Last sind als eine Offenbarung. Entwicklerhefte scherensich nicht darum, was raffiniert ist oder was Spaß machen könnte, wennSie gerade etwas freie Zeit haben (wann war das denn das letzte Mal derFall?), sondern sie konzentrieren sich auf das, was Sie benötigen, umetwas einfach »in Gang zu bekommen«. Sie sollten also keine Vorlesungerwarten, sondern praktische Übungen. Wenn Sie sich für grundlegendeKonzepte, Architekturen und UML-Diagramme interessieren, kann ichIhnen unsere Animal-Bücher und Nutshell-Bände wärmstens empfehlen.Wenn Sie Antworten auf alle Probleme unter der Sonne suchen, sind dieRezeptsammlungen unserer Kochbücher das Richtige für Sie. Und wennSie auf besonders geheimnisvolle und bisweilen etwas sonderbareAnwendungsmöglichkeiten der Technologien aus sind, werden Sie sichfür die Hacks-Bücher begeistern. Aber wenn Sie durch und durch Pro-grammierer sind und einfach nur mit Ihrer Arbeit weiterkommen möch-ten, dann brauchen Sie ein Entwicklerheft. Die Kaffeeflecken und dieRandnotizen zeigen: Was hier steht, gelangt direkt aus dem Kopf einesEntwicklers zu Ihnen. Ich hoffe, Sie finden Gefallen daran ... uns hat esviel Spaß gemacht, daran zu arbeiten.

Entwicklerhefte sind ...An Beispielen orientierte Leitfäden

Wie Sie im Abschnitt »Aufbau der Entwicklerhefte« sehen, sind dieEntwicklerhefte komplett an Beispielprogrammen orientiert. Fast aufjeder Seite finden Sie Code-Beispiele, und dies ist Code, der etwasmacht – keine trivialen »Hello World!«-Programme, die nicht mehrwert sind als das Papier, auf das sie gedruckt sind.

Für Entwickler geschriebenHaben Sie auch schon Bücher gelesen, die sich an spitzfindige Bossezu richten scheinen, die voller Buzzwords sind und eher Marketing-Materialen gleichen als Programmierbüchern? Solche Bücher ken-nen wir auch, und diese Reihe bildet die Antithese dazu. Tatsächlichwird ein gutes Entwicklerheft für jemanden, der nicht programmie-ren kann, kaum verständlich sein. (Sagen Sie nicht, wir hätten Sie

Über die Entwicklerhefte IX

nicht gewarnt!) Aber genau das ist zu erwarten, und für Entwickler ...könnte es besser nicht sein.

Angenehm durchzuarbeitenHaben Sie wirklich die Zeit herumzusitzen und etwas zu lesen, daskeinerlei Spaß macht? Wenn ja, dann mögen Sie vermutlich tausend-seitige Sprachreferenzen – aber wenn es Ihnen so geht wie allenanderen, dann sind Entwicklerhefte viel passender für Sie. Prakti-sche Programmierbeispiele, knappe, um die anwendbaren Beispieleherum zentrierte Dialoge und gelegentlich sogar etwas Humor – diessind die Zutaten eines guten Entwicklerhefts.

Es geht ums Tun, nicht darum, über das Tun zu redenWenn Sie ein Buch spät in der Nacht lesen möchten, ohne dass einComputer in der Nähe steht, sind diese Bücher für Sie vermutlichnicht besonders hilfreich. Wir wollen, dass Sie programmieren, wäh-rend Sie mit diesem Buch arbeiten, und dabei tief in den Bytecodeeintauchen. Aus diesem Grund finden Sie in den EntwicklerheftenCode, Code und immer wieder Code. Werfen Sie also Ihren Editor an,bevor Sie einsteigen.

Entwicklerhefte sind nicht ...Vorlesungen

Entwicklerhefte werden nicht einfach von irgendjemandem ge-schrieben – die Autoren müssen wirkliche Programmierer sein, dievorzugsweise abends zu lange auf bleiben, um noch ein bisschen zuprogrammieren. So großartig manche Vollzeit-Autoren, Akademikerund Theoretiker in ihren Bereichen auch sein mögen, diese Bücherhandeln von der harten Wirklichkeit des Programmierens. Sie sindvoller Anleitungen und nicht voll weiser Sprüche.

Gefüllt mit konzeptionellen Zeichnungen und KlassenhierarchienDies ist, wie gesagt, kein Nutshell-Buch. Sie finden hier keinen 100-seitigen Index, in dem jede Methode aufgeführt ist, und Sie sehenkeine ganzseitigen UML-Diagramme mit Methoden, Vererbungsbäu-men und Flussdiagrammen. Was Sie Seite für Seite finden, ist Quell-code. (Erkennen Sie schon das immer wiederkehrende Thema?)

Lang in der Erklärung, schwach in der AnwendbarkeitAnscheinend müssen viele Programmierbücher heutzutage drei, vieroder mehr Kapitel haben, bevor man überhaupt auf irgendwelchenfunktionierenden Code stößt. Ich weiß nicht, wer Autoren auf dieIdee gebracht hat, ihre Leser so lange warten zu lassen, aber es ist

X Über die Entwicklerhefte

sicher niemand, der für diese Reihe arbeitet. Wir glauben, dassetwas falsch läuft, wenn Sie nicht innerhalb von zehn Seiten zumProgrammieren kommen. Darüber hinaus sind diese Bücher randvollmit praktischen Anwendungen, die von einem einfachen Beispielausgehen, aber schnell dazu führen, dass Sie eine konkrete Aufgabein Ihrem Arbeitsalltag lösen können.

Aufbau der EntwicklerhefteDie Entwicklerhefte versuchen, Informationen anders zu vermitteln alsdie üblichen Bücher. Dementsprechend sind sie auch anders organisiert.Kapitel gibt es nach wie vor, aber damit hört die Ähnlichkeit eines Notiz-buchs zu einem traditionellen Buch über Programmierung auch schon auf.Zunächst werden Sie bemerken, dass sich alle Überschriften eines Kapi-tels mit einer bestimmten Aufgabe beschäftigen. Beachten Sie, dass wirdas Wort Aufgabe verwenden, nicht etwa Thema. Das ist eine der we-sentlichen Eigenschaften dieser Bücher: Es geht in erster Linie darum,etwas zu tun. Jede Überschrift repräsentiert eine Aufgabe. Eine Aufgabeist das, wonach es klingt: die zum Erreichen eines bestimmten Ziels nöti-gen Schritte. Der erste Satz einer Aufgabe lautet typischerweise »Wie ma-che ich das?”, denn dies ist die zentrale Frage einer Aufgabe. In diesenAbschnitten wird hemmungslos und bis ins Detail programmiert.

Ein letzter Hinweis: Auf vielen Seiten finden Sie auf den Seitenrandgekritzelte Notizen. Das ist keine Dekoration: Es handelt sich um kurzeZusammenfassungen der jeweiligen Abschnitte. Bei den kürzeren undlängeren Code-Abschnitten finden Sie hier außerdem den Namen derDatei, die gerade modifiziert wird.

Alles in allem, denken Sie immer daran: Diese Bücher sind...

Reine Praxis, kein Vortrag

Brett McLaughlin, Schöpfer dieser Serie

XI

Über dieses Buch

Was ist eigentlich NetBeans? Auf den ersten Blick ist NetBeans eine her-vorragende integrierte Entwicklungsumgebung, die als reine Java-Anwendung auf vielen Plattformen wie Windows, Linux, Solaris und MacOS läuft. Neben der Unterstützung mehrerer Sprachen – derzeit Java, Rubyund C/C++ – bietet sie über so genannte »Packs« alles, was wir für dieEntwicklung von Java ME-, Java SE- und Java EE-Applikationen benö-tigen. Ein Vorwort ist sicherlich nicht der passende Ort, um alle Featureseiner solch umfangreichen IDE aufzuzeigen, aber insbesondere die exzel-lenten visuellen Editoren für Swing und Web-Anwendungen sowie dieKollaborationstools und der Profiler sind einen Blick wert.

NetBeans ist aber noch wesentlich mehr. Die NetBeans IDE wurde vonAnfang an vollständig modular entwickelt und ist durch die Fähigkeit,diese Module dynamisch laden zu können, in ihrem Umfang sehr flexi-bel. Im Unterschied zu anderen bedeutenden IDEs basiert sie vollständigauf Java-Standards und verwendet Swing als GUI-System. Das NetBeans-Team hat daher schon sehr früh enorme Anstrengungen unternommen,sich selbst ein Framework für die Entwicklung von Swing-basiertenApplikationen zu schaffen. Dieses Framework berücksichtigt Aspekte wiedie Bereitstellung von Bausteinen für reiche und konsistente Benutzer-oberflächen, Ressourenverwaltung, Konfiguration, kontextsensistive Hilfeund nicht zuletzt Verteilungs-, Installations- und dynamische Aktualisie-rungsfähigkeiten. Da sehr viele Desktop-Applikationen ähnliche techni-sche Anforderungen erfüllen müssen, lag es nahe, den Java-Entwicklernneben dem Tooling auch das Framework zur Verfügung zu stellen – dieNetBeans-Plattform war geboren.

Sie können sowohl

die NetBeans

IDE als auch die

Plattform der-

zeit in der

Version 6 unter

www.netbeans.org

herunterladen.

Einführende

Videos finden

Sie unter

www.netbeans.tv,

eine stets infor-

mative und unter-

haltsame Quelle

für Informatio-

nen zur Platt-

form ist Geert-

jans Weblog unter

blogs.sun.com/

geertjan.

XII

Sowohl die Plattform als auch das Tooling sind seit Juni 2000 OpenSource und stehen sowohl unter der CDDL als auch der GPL v2. Elf Jahrenach dem Beginn der Entwicklung steht NetBeans heute in der Version 6zur Verfügung. Sun Microsystems ist zwar weiterhin Hauptsponsor desProjekts, die Bedeutung der Community für die Entwicklung von Net-Beans wächst jedoch rasant. Mittlerweile sind mehr als 500.000 Mitglie-der registriert, bringen ihre Erfahrungen ein und verbessern NetBeansstetig. Immer mehr Partner fördern das Projekt, und die stetig wach-sende Liste der auf der NetBeans-Plattform basierenden Referenzpro-jekte belegt die Akzeptanz der Plattform.

Aufbau dieses BuchsDieses Buch hat nicht den Anspruch, Ihnen die vollständige Plattform mitall ihren Aspekten zu zeigen. Vielmehr soll Ihnen möglichst zügig ein pra-xisbezogener Eindruck der Rich-Client-Entwicklung mit der NetBeans IDEund der NetBeans-Plattform verschafft werden. Das Ziel ist, Ihnen zu zei-gen, wie die NetBeans-Plattform Sie bei der Entwicklung hochqualita-tiver Rich-Client-Applikationen unterstützen kann, was die wesentlichenKonzepte sind und wo Stolpersteine liegen. Dieses Entwicklerheft sollkein ausführliches Referenzwerk ersetzen – dafür empfehle ich im Übri-gen »Rich Client Programming« von Boudreau, Tulach und Wielenga –,sondern Sie an die Hand nehmen und durch die Entwicklung einer Rich-Client-Applikation führen. Der zentrale Treiber dieses Buches ist dahereine Beispielapplikation, die sich vom ersten bis zum letzten Kapiteldurchzieht. Wir werden eine Aufgabenverwaltung implementieren, diezwar einfach gehalten ist, jedoch die meisten wesentlichen Aspekte derRich-Client-Entwicklung berührt. Wir werden dabei so vorgehen, dasswir jeweils mit dem Wissensstand des aktuellen Kapitels arbeiten und dieApplikation Stück für Stück erweitern und bestehende Teile gegebenen-falls so umschreiben, dass letztlich eine vollständige Applikation entsteht.

Im Einzelnen werden wir uns die folgenden Themen ansehen:

ModuleModule sind die grundlegenden Bausteine unserer Applikationen.Wir werden uns ansehen, welche Eigenschaften sie haben, wieAbhängigkeiten zwischen Modulen aufgelöst werden und wie sieversioniert werden. Zudem beschäftigen wir uns mit ihrem Lebens-zyklus und unseren Eingriffsmöglichkeiten. Bereits in diesem Kapitelwerden wir unsere Beispielapplikation vorstellen und mit ihrer Ent-wicklung beginnen.

XIII

FormulareBeinahe jede Desktop-Applikation benötigt eine Vielzahl von Formu-laren, um Informationen darzustellen und sie zu erfassen. Wir wer-den uns ansehen, wie Formulare erstellt werden, wie ihr Layoutbestimmt wird und wie wir eine Ereignisbehandlung implementie-ren können.

Windows APIDie Windows API bietet uns Zugriff auf ein komplexes Fenstersys-tem. Wir werden uns anschauen, wie Fenster erzeugt werden, wieihr Lebenszyklus aussieht und wie wir in diesen eingreifen können.Zudem werden wir lernen, wie Fenster im Standardlayout positio-niert werden, wie dieses Layout angepasst werden kann und wieGruppen von Fenstern gebildet werden können.

Lookup APIDie Lookup API ist für die Entwicklung von Plattform-Applikationenvon besonders großer Bedeutung. Wir werden uns ansehen, wie mitHilfe von Lookups Dienste gefunden werden, eine lose gekoppelteKommunikation zwischen Komponenten ermöglicht wird und überListener dynamische Lookup-Inhalte realisiert werden. Zudem wer-den wir lernen, wie ein Lookup als Stellvertreter für einen anderendienen kann und warum dies die Grundlage für die globale Kontext-sensitivität ist.

ActionsActions sind durch den Benutzer ausführbare Aktionen. Wir werdenuns ansehen, wie globale Actions erzeugt, in Menüs, Toolbars etc.eingehängt und wie sie an Tastenkombinationen gebunden werden.

Nodes & Explorer APIDiese beiden APIs bieten uns eine ausgeklügelte MVC-Implementie-rung mit deren Hilfe wir beliebige Fachmodelle mit wenig Aufwandin wiederverwendbaren Views darstellen können. Wir werden unsanschauen, wie Nodes zur Präsentation von Modellobjekten verwen-det und in Explorer Views dargestellt werden. Wir werden dazusowohl flache als auch hierarchische Strukturen verwenden und unsansehen, mit wie wenig Aufwand die anzeigende View ausge-tauscht werden kann. Anschließend werden wir uns mit der langläu-figen Ermittlung von Nodes beschäftigen und sehen, wie dieNetBeans-Plattform kontextsensitive Aktionen unterstützt. Zu guter

XIV

Letzt werden wir uns ansehen, wie die Properties der Nodes überPropertyViews und PropertyEditoren dargestellt und editiert werdenkönnen.

Filesystems APIDie Filesystems API bietet Zugriff auf virtuelle Dateisysteme. Wir wer-den uns anschauen, wie wir auf das Konfigurations- und das lokaleDateisystem zugreifen können. Zudem werden wir uns mit frei ver-gebbaren Attributen der virtuellen Dateien beschäftigen.

Datasystems APIDie Datasystems API ermöglicht uns, auf Dateiinhalte zuzugreifen. Wirwerden uns ansehen, wie wir die Plattform um die Unterstützungweiterer Dateitypen ergänzen und wie die Fähigkeiten im Umgangmit den Dateiinhalten abhängig vom Status der Datei geändert wer-den können.

Dialogs APIDialoge reichen von einfachen Benachrichtigungen bis zu Wizards.Wir werden uns daher anschauen, wie wir einfache Benachrich-tigungen, Standarddialoge, eigene und mehrseitige Dialoge anzeigenkönnen.

BrandingBranding ermöglicht, die Applikation in ihrem Erscheinungsbildanzupassen. Wir werden uns exemplarisch ansehen, wie wir denSplash Screen austauschen können.

Distribution & UpdatesUm unsere Software ausliefern zu können, werden wir uns die ver-schieden Distributionsformen für Plattform-Applikationen ansehen,einen Exkurs zur Generierung von Installern machen und unsschließlich der Online-Aktualisierung zuwenden.

Im Buch verwendete KonventionenKursive Schrift

verwenden wir für Datei- und Verzeichnisnamen, URLs und erstmalseingeführte Begriffe.

Nichtporportionalschrift

wird im Fließtext für Methoden und Schlüsselwörter benutzt, außer-dem durchgehend für die Quellcodebeispiele.

XV

KAPITÄLCHEN

verwenden wir für GUI-Elemente wie Buttons, Schaltflächen undMenüelemente.

Das BeispielprojektAls Beispielprojekt werden wir eine einfache Aufgabenverwaltung ent-wickeln. Mit ihr werden Hierarchien von Aufgaben erzeugt, modifiziert,angezeigt, gefiltert und gelöscht werden können. Wir werden dazu For-mulare, Wizards und lose gekoppelte Master-Detail-Views erstellen unddie Funktionen über kontextsensitive Aktionen in Menüs, Toolbars undKontextmenüs anbieten. Für die Persistierung werden wir die Plattformum die Unterstützung eines neuen Dateityps erweitern. Zudem werdenwir eine Integration in die Standardkonfiguration und das Hilfesystemvornehmen, das Branding durchführen und einen Installer zur Distribu-tion erzeugen. Abgerundet wird die Applikation schließlich über dieFähigkeit, sich über ein Update-Center zu aktualisieren.

Der Source-Code der Beispielapplikation ist auf der begleitenden Web-site www.netbeansrcp.com veröffentlicht. Sie finden dort sowohl denendgültigen Stand der Applikation als auch die Zwischenstände zumEnde jeden Kapitels.

Abbildung 0-1: Beispielapplikation

XVI

DanksagungenAn der Entstehung dieses Buches waren viele Personen beteiligt, beidenen ich mich an dieser Stelle bedanken möchte. Ausdrücklich bedan-ken möchte ich mich bei Frau Haite vom O’Reilly Verlag für das entgegen-gebrachte Vertrauen und die tolle Unterstützung in allen Phasen diesesProjektes. Mein Dank gilt auch Markus Jais, Jens Boß und Geertjan Wie-lenga für das Review des Buches, die mir mit ihren Ideen und Kritikensehr geholfen haben. Vor allem aber bedanke ich mich bei meiner Ver-lobten Sabine, die in den vergangenen Monaten viel Geduld mit mir hatteund mir trotz Fernbeziehung erlaubte, einen großen Teil meiner Freizeitmit dem Schreiben dieses Buches zu verbringen.

1

Kapitel 1 KAPITEL 1

Module

In diesem ersten Kapitel werden wir uns mit Modulen und modularerEntwicklung beschäftigen. Wir werden uns anschauen, was Module aus-machen und wie sie in der NetBeans- Plattform angelegt werden.Anschließend werden wir uns mit der Konfiguration von Modulen, insbe-sondere mit der Verwaltung von Abhängigkeiten und Versionierung aus-einandersetzen. Abschließend werden wir auf den Lebenszyklus vonModulen eingehen und sehen, wie wir in diesen programmatisch ein-greifen können.

Modulare EntwicklungMit der stetig wachsenden Komplexität von Software gewinnt die Modula-risierung zunehmend an Bedeutung. Immer kürzere Produktzyklen, stetigwachsender Funktionsumfang und gleichzeitig steigendes Bewusstsein fürSoftwarequalität lassen sich mit den herkömmlichen Entwicklungsmetho-den nicht mehr in Einklang bringen. Gerade der erhöhte Zeitdruck führthäufig dazu, dass ein an sich klares Design zunächst an wenigen Stellenaufgeweicht wird und Abhängigkeiten zwischen Komponenten einge-führt werden, die nie miteinander gekoppelt werden sollten. Mit jederWartungsmaßnahme und jeder Erweiterung kommen immer mehr dieserkleinen Verstöße hinzu, bis schließlich ein heilloses Chaos herrscht,Erweiterungen und selbst Bugfixes kaum noch möglich sind und man sichbei jeder Änderung fragen muss, welche ungewollten Auswirkungen sichwohl diesmal zeigen werden. Der Testaufwand für eine solche gewach-sene Applikation steigt ins Unermessliche, bis irgendwann entschiedenwird, dass eine vollständige Neuauflage der Applikation entwickelt wer-den muss und der Reigen von vorne beginnt.

In diesem Kapitel:

• Modulare Ent-wicklung

• Eigenschaften eines Moduls

• Anlage eines Moduls

• Abhängigkeiten verwalten

• Versionierung

• Installation von Modulen

• Exkurs: Die Bei-spielapplikation

2 Kapitel 1: Module

Eine Lösung dieses Problems liegt in der Einführung von Modulen.Module sind zunächst einmal in sich abgeschlossene Softwarekompo-nenten, die nach außen über eine wohldefinierte Schnittstelle anzuspre-chen sind und ihre Implementierung hinter dieser Schnittstelleverstecken. In NetBeans wird jedes Modul als selbständiges Projekt abge-bildet. Jedes grobgranulare Feature einer Applikation wird dabei alseigenes Modul entworfen, so dass jedes Modul einen überschaubarenUmfang hat. Der oben beschriebene Wildwuchs kann innerhalb einesModuls im Grunde genommen genauso auftreten wie in herkömmlichenApplikationen, jedoch sind sämtliche Klassen eines Moduls auf dieUmsetzung eines einzigen Features gerichtet, so dass sie höchstwahr-scheinlich ohnehin zusammenarbeiten müssen und somit voneinanderabhängig sind. Zudem erleichtert der beschränkte Umfang die Einhal-tung eines sauberen Entwurfs sehr deutlich.

Das oben beschriebene schleichende Chaos in der gesamten Applikationkann bei dieser Art der Entwicklung jedoch kaum auftreten, da die Imp-lementierung des Features lediglich über die öffentliche Schnittstelleansprechbar ist. Die Abhängigkeiten im Gesamtsystem sind daher sehreingeschränkt und planbar. Eine Abweichung vom Plan und damit derbeschriebene Wildwuchs sind generell nicht möglich.

Neben diesem Vorteil bei der Strukturierung der Applikation hat diemodulare Entwicklung auch ganz handfeste Vorteile für den Endanwen-der. Da das NetBeans-Module-System dynamisch ist, können Module unddamit Features dynamisch hinzugeladen, entfernt oder ausgetauschtwerden. Damit ist eine weitgehende Anpassbarkeit der Applikation anden Benutzer sehr leicht umsetzbar, was gerade bei Enterprise-Applika-tionen, die für eine Vielzahl unterschiedlicher Nutzerprofile eingesetztwerden, sehr nützlich sein kann.

Schauen wir uns nun aber konkreter an, was Module ausmachen.

Eigenschaften eines ModulsEin Modul muss bestimmte Eigenschaften aufweisen, damit sich diegewünschten Vorteile ergeben können:

DeploymentformatSämtliche Ressourcen, die eine Komponente ausmachen, müssen alseine deploybare Einheit zusammengefasst werden können.Nahe liegendes Deploymentformat ist im Java-Umfeld sicherlich eineJar-Datei. Sie kann beliebig viele Ressourcen bündeln und bietet mit

Module stellen

Softwarekompo-

nenten mit wohl-

definierten

Schnittstellen

dar und verste-

cken ihre Imple-

mentierung

Eigenschaften eines Moduls 3

ihrem Manifest die Möglichkeit, Meta-Informationen zu speichern.NetBeans-Module werden daher wie viele andere Komponentenauch in einer Jar-Datei deployt, die zusätzliche Informationen inihrem Manifest aufnimmt.

Eindeutige BezeichnungJede Komponente muss eine eindeutige Identität haben. NetBeans-Module erweitern das Manifest um den Eintrag OpenIDE-Module, der den applikationsweit eindeutigen Namen des Modulsspezifiziert.

VersionierungJede Komponente muss darüber hinaus angeben können, in welcherVersion sie vorliegt.NetBeans-Module unterscheiden hinsichtlich der Versionierung zwi-schen den Versionen der Spezifikation und der Implementierung. Die Spezifikationsversion zeigt an, welche Version der öffentlichenSchnittstelle das Modul realisiert. Sie wird im Manifest-Eintrag Open-IDE-Module-Specification-Version festgelegt und entspricht dem übli-chen Dewey-Format. Grundsätzlich wird davon ausgegangen, dasshöhere Versionen abwärtskompatibel sind.Die Implementierungsversion zeigt an, welchen Implementierungs-stand das Modul hat. Diese Version dient nicht dem Vergleich derKompatibilität des gefundenen mit dem geforderten Modul und kanndaher lediglich auf Übereinstimmung mit einer gewünschten Versiongeprüft werden. Sie wird im Manifest-Eintrag OpenIDE-Module-Im-plementation-Version festgelegt.

Öffentliche Schnittstelle Jedes Modul definiert eine öffentliche Schnittstelle, über die seineFunktionalität angesprochen werden kann. Herkömmliche Verfahren, um auswuchernde Abhängigkeiten inner-halb einer Software in den Griff zu bekommen, beruhen häufig aufKonventionen. Typen in bestimmten Paketen dürfen vereinbarungs-gemäß nur indirekt, z.B. über Fassaden angesprochen werden. Diewohlgemeinten Konventionen werden aber häufig genug dem Zeit-druck geopfert.Komponentensysteme mit eigener Laufzeitumgebung erzwingen inder Regel die Einhaltung der Regeln. Innerhalb eines Moduls kön-nen beliebig viele Klassen public sein und von anderen Klassen desModuls direkt angesprochen werden. Andere Module können jedochnur auf die öffentlichen Klassen zugreifen, die in ausdrücklich alsöffentlich deklarierten Paketen liegen.

4 Kapitel 1: Module

NetBeans liefert mit dem Module-System eine solche Laufzeitumge-bung. Über den Manifest-Eintrag OpenIDE-Module-Public-Packageswerden sämtliche Pakete deklariert, auf die andere Module zugrei-fen dürfen. Die Laufzeitumgebung verwaltet ein System aus Class-Loadern, das Klassen eines Moduls lediglich Zugriff auf den eigenenModulinhalt sowie die Pakete der öffentlichen Schnittstellen derjeni-gen Module erlaubt, zu denen das Modul eine Abhängigkeit deklariert.

Deklarierte AbhängigkeitenJede Komponente muss zudem deklarieren, welche anderen Kompo-nenten sie benutzen möchte.NetBeans sieht hierfür den Manifest-Eintrag OpenIDE-Module-Dependencies vor. Wie zuvor erläutert, sorgt die Laufzeitumgebungdafür, dass das Modul lediglich zu den öffentlichen Paketen dieserModule Zugriff erhält.

LebenszyklusJede Komponente muss über einen definierten Lebenszyklus verfü-gen, der durch die Laufzeitumgebung sichergestellt ist.NetBeans Module Runtime sorgt dafür, dass Module geladen undkonfiguriert werden, dass ggf. eigener Initialisierungscode ausge-führt wird, Module bei Bedarf nachgeladen und entladen werden.

Anlage eines ModulsNachdem wir nun viel Theorie gehört haben, wollen wir zwei Moduleanlegen und sie so konfigurieren, dass ein Modul auf die öffentlicheSchnittstelle des anderen Moduls zugreifen kann.

Wie mache ich das?Zunächst legen wir ein neues Module-Suite-Projekt an. Die Module Suitedient als Container für Module und repräsentiert in der Regel eine Appli-kation. Über sie wird die zu verwendende Plattform konfiguriert und dieApplikation gebrandet.

Dazu rufen wir mit FILE NEW PROJECT den New Project Wizard auf, wäh-len NETBEANS MODULES MODULE SUITE und geben den Namen des Projekts»ModuleExamples« sowie seinen Standort ein (siehe Abbildung 1-1).

Nun können wir dieser Suite ein neues Modul hinzufügen.

Eine Module Suite

dient als Contai-

ner für Module

und repräsentiert

eine Applikation.

Anlage eines Moduls 5

Dazu rufen wir das Kontextmenü des Knoten MODULES unserer ModuleSuite MODULEEXAMPLES im Project Explorer (oben links) auf und wählen ADD

NEW. Im nun erscheinenden NEW MODULE PROJECT-Wizard geben wir denNamen des Moduls com.netbeansrcp.helloservice (siehe Abbildung 1-2)sowie seinen Standort an (siehe Abbildung 1-3). Die Zugehörigkeit zurrichtigen Module Suite wird automatisch erkannt.

Abbildung 1-1: Eine neue Module Suite anlegen

Abbildung 1-2: Wir fügen ein neues Modul hinzu ...

6 Kapitel 1: Module

Diesem Modul fügen wir nun eine öffentliche Klasse HelloService hinzu,indem wir das Kontextmenü des Knotens HELLOSERVICE SOURCE

PACKAGES COM.NETBEANSRCP.HELLOSERVICE aufrufen, NEW JAVA CLASS

wählen und den Wizard ausführen.

Der Klasse HelloService fügen Sie bitte die folgende Methode hinzu:

public void hello(String name) { System.out.println("Hello " + name + "!");}

Was ist da gerade geschehen?Mit Hilfe des Wizards haben wir nun ein neues Modul angelegt. DasModul beinhaltet mehrere Konfigurationsdateien, von denen die wich-tigsten manifest.mf und layer.xml sind. Beide Dateien sind unter demKnoten HELLOSERVICE IMPORTANT FILES zu finden. Die layer.xml werdenwir im Laufe der kommenden Kapitel noch häufiger ansprechen. IhrInhalt soll uns zum jetzigen Zeitpunkt jedoch noch nicht interessieren.Das Manifest haben wir bereits besprochen, und derzeit enthält es nurwenige Einträge:

Manifest-Version: 1.0OpenIDE-Module: com.netbeansrcp.helloserviceOpenIDE-Module-Layer: com/netbeansrcp/helloservice/layer.xmlOpenIDE-Module-Localizing-Bundle:

com/netbeansrcp/helloservice/Bundle.propertiesOpenIDE-Module-Specification-Version: 1.0

Abbildung 1-3: ... und geben seinen Standort an.

HelloService.java

Die wichtigsten

Konfigurations-

dateien für Mo-

dule sind

manifest.mf und

layer.xml.

Manifest.mf

Abhängigkeiten verwalten 7

Abhängigkeiten verwaltenNun wollen wir den HelloService natürlich auch aus einem anderenModul heraus benutzen.

Legen Sie daher bitte auf die gleiche Weise ein zweites Modul namensHelloClient an, und fügen Sie eine Klasse HelloClient mit folgenderMethode ein:

public static void main(String[] args) { new HelloService().hello("NetBeans");}

Diese neue Klasse lässt sich momentan noch nicht kompilieren, weilHelloService nicht gefunden werden kann. Auch das Einfügen einesentsprechenden Import-Statements kann dem nicht abhelfen, da dieUrsache in der erzwungenen Isolation von Modulen liegt. Bevor eineKlasse aus dem Modul HelloClient eine Klasse aus dem ModulHelloService nutzen kann, müssen zwei Voraussetzungen erfüllt sein:

1. Die Klasse HelloService muss zur öffentlichen Schnittstelle desModuls gehören.

2. Das Modul HelloClient muss seine Abhängigkeit vom HelloServiceöffentlich deklarieren.

Wie mache ich das?Zunächst müssen wir also den HelloService zur öffentlichen Schnitt-stelle des Moduls hinzufügen. Dazu rufen wir das KONTEXTMENÜ DES MODULS

HELLOSERVICE auf und wählen PROPERTIES. Unter API VERSIONING sehen wirnun eine Liste der Pakete unseres Moduls und können diejenigen aus-wählen, die vollständig zur öffentlichen Schnittstelle gehören sollen(Abbildung 1-4). In unserem Fall ist das com.netbeansrcp.helloservice.Einzelne Typen können nicht veröffentlicht werden.

Nun müssen wir noch die Abhängigkeit des Moduls HelloClient zuHelloService deklarieren. Dazu rufen wir das KONTEXTMENÜ DES MODULS

HELLOCLIENT auf und wählen PROPERTIES. Unter LIBRARIES können die Abhän-gigkeiten zu eigenen und NetBeans-Modulen deklariert werden. KlickenSie bitte auf ADD DEPENDENCY, und beginnen Sie in das fokussierte Textfeldden Namen der Klasse zu schreiben, auf die Sie zugreifen möchten. Net-Beans ermittelt während der Eingabe automatisch die in Frage kommen-den Module und stellt sie als Liste dar, siehe Abbildung 1-5. Wählen Siedas Modul HelloService, und bestätigen Sie die Auswahl. Den Properties-Dialog können wir ebenfalls mit einem Klick auf OK beenden.

HelloClient.java

Die Plattform

isoliert Module

über eigene Class-

loader. Abhängig-

keiten müssen

deklariert wer-

den, und der

Zugriff kann nur

auf die öffentli-

che Schnittstelle

erfolgen.

Die öffentliche

Schnittstelle

besteht aus Pake-

ten. Auf Typen,

die nicht in Pake-

ten der öffent-

lichen Schnitt-

stelle liegen, kann

auch dann nicht

zugegriffen wer-

den, wenn sie

public sind.

8 Kapitel 1: Module

Sollten Sie in der Klasse HelloClient noch kein import-Statement fürcom.netbeansrcp.helloservice.HelloService stehen haben, so ergän-zen Sie es bitte. Die Klasse lässt sich nun kompilieren.

Abbildung 1-4: Öffentliche Schnittstelle deklarieren

Abbildung 1-5: Abhängigkeiten deklarieren

Versionierung 9

Was ist da gerade geschehen?Mit Hilfe von Dialogen haben wir zum einen die öffentliche Schnittstelledes Moduls HelloService definiert und zum anderen die Abhängigkeitdes Moduls HelloClient hiervon deklariert. Klassen aus dem ModulHelloClient können nun auf Klassen zugreifen, die zur öffentlichenSchnittstelle des Moduls HelloService gehören.

VersionierungZusätzlich zu der Information, von welchen Modulen ein Modul abhängigsein soll, müssen wir noch die Information verwalten, welche Version derModule wir überhaupt meinen. NetBeans unterscheidet zwischen Versio-nen der Spezifikation und der Implementierung.Die Spezifikationsversion wird in der Dewey-Notation angegeben undbeinhaltet in der Regel die Hauptversionsnummer, die für wesentlicheErweiterungen erhöht wird, die Nebenversionsnummer, die für Erweite-rungen erhöht wird, und den Patchlevel, der Bugfixes u. Ä. anzeigt (z.B.»Mac OS X in der Version 10.4.10«).Die Implementierungsversion zeigt einen konkreten Entwicklungsstandan und kann nur auf Übereinstimmung geprüft werden.

Exemplarisch wollen wir für das Modul HelloService die Version 1.2.5deklarieren.

Wie mache ich das?Zunächst konfigurieren wir das Modul HelloClient so, dass es Hello-Server in der Version 1.2.5 benötigt. Dazu rufen wir das Kontextmenüdes Moduls HelloClient auf und wählen PROPERTIES. Unter LIBRARIES

selektieren wir die Abhängigkeit zum HelloService und klicken auf EDIT.Tragen Sie bitte als Spezifikationsversion 2.1.5 ein (Abbildung 1-6), undbestätigen Sie die Dialoge.

Wenn Sie nun versuchen, das Projekt zu bauen, bekommen Sie die Mel-dung, dass der Build gebrochen ist, weil dazu das Modul HelloService ineiner Version größer 2.1.5 vorliegen müsste.

...harness/build.xml:97: Cannot compile against a module:

/Users/jpe/NetBeansProjects/ModuleExamples/build/cluster/modules/com-netbeansrcp-helloservice.jar because of dependency: com.netbeansrcp.helloservice > 2.1.5

BUILD FAILED (total time: 1 second)

Die Versionierung

von Modulen er-

folgt sowohl für

die Spezifikation

als auch die Im-

plementierung.

Die Plattform

überprüft das

Vorliegen der

benötigten Versio-

nen automatisch.

10 Kapitel 1: Module

Um den Build wieder durchzubekommen, deklarieren wir für das ModulHelloService die Version 2.1.3. Dazu rufen wir das Kontextmenü desModuls HelloService auf und wählen PROPERTIES. Unter API VERSIONING

tragen Sie bitte die Spezifikationsversion 2.1.5 ein (siehe Abbildung 1-7).

Versuchen Sie nun erneut, das Projekt zu kompilieren. Der Build wird nunerfolgreich sein, da wir die öffentliche Schnittstelle von HelloServiceeingebunden haben.

Abbildung 1-6: Abhängigkeit zu Spezifikationsversion deklarieren

Abbildung 1-7: Abhängigkeit zu Spezifikationsversion deklarieren

Installation von Modulen 11

Was ist da gerade geschehen?Wir haben soeben gesehen, wie über die Properties die Spezifikations-version eines Moduls gesetzt wird, und gezeigt, dass NetBeans schonbeim Build erzwingt, dass wir stets ein Modul der gewünschten Versionoder neuer vorliegen haben.

Installation von ModulenModule müssen installiert werden, damit die Laufzeitumgebung ihrenLebenszyklus steuern kann. Die Installation funktioniert in NetBeansgrundsätzlich deklarativ und wurde bereits durch die Wizards umgesetzt.

Wie greife ich in den Lebenszyklus ein?Wollen wir in den Lebenszyklus programmatisch eingreifen, können wirdas über einen speziellen Module-Installer tun. Die Klasse ModuleInstalldefiniert Methoden, die die Laufzeitumgebung zu bestimmten Ereignis-sen im Leben des Moduls aufruft. Diese Methoden dienen in der Regelder reinen Information, können aber auch verwandt werden, um z. B. dasSchließen der Applikation zu verhindern.

validate() kann überschrieben werden, um das Laden des Moduls zuverhindern. Das ist insbesondere dann sinnvoll, wenn bestimmte Voraus-setzungen für das korrekte Funktionieren des Moduls wie z.B. das Vor-handensein einer gültigen Lizenz nicht gegeben sind.

restored() kann überschrieben werden, um Initialisierungen desModuls vorzunehmen. Zugunsten der Performance sollten Sie jedochüberlegen, ob die Initialisierung nicht erst bei Bedarf, also lazy, ausge-führt werden sollte.

closing() kann überschrieben werden, um das Schließen der Applika-tion durch die Rückgabe von false zu verhindern.

close() informiert über das bevorstehende Schließen der Applikation.

Um einen eigenen Module-Installer zu erzeugen, rufen wir das Kontext-menü des Moduls HelloService auf, wählen NEW OTHER MODULE

INSTALLER, bestätigen die vorgegebenen Werte und beenden den Dialog(siehe Abbildungen 1-8 und 1-9).

Bitte überschreiben Sie restored() wie folgt:

@Overridepublic void restored() { System.out.println("HelloService() restored.");}

Ein ModuleIn-

staller erlaubt uns

den Eingriff in

den Lebenszyklus

eines Moduls.

Installer.java